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DETAILED ACTION 

Response to Arguments 

1 . Applicant's arguments with respect to amended claims 1-9, 1 1-25, 27-33 have been 
considered but are moot in view of the new ground(s) of rejection. 

Regarding amended claims 1-4, 17-20, and 33 which are provisionally rejected on the 
ground of nonstatutory obviousness-type double patenting, it is noted that applicant has not 
response to the rejection, thus it is admission that applicant agrees with the rejection. 
Accordingly, provisional nonstatutory obviousncss-type double patenting rejection is sustained. 

Regarding amended claims 1-9, 11-25, 27-33, the applicant argued that, ". . .Olsson 
fails to discloses "additional packets " associated with request or that such additional packets 
are received prior to establishing a request protocol based connection.... a pass-through class to 
which additional packets are assigned and received additional packets are forwarded even if a 
number of packets forwarded from the class of their associated request packets has reached a 
maximum count. . .Barach does not disclose or suggest additional packets " associated with 
request or that such additional packets are received prior to establishing a request protocol 
based connection.... a pass-through class to which additional packets are assigned and received 
additional packets are forwarded even if a number of packets forwarded from the class of their 
associated request packets has reached a maximum count . . .Valencia fails to disclose or suggest 
additional packets " associated with request or that such additional packets are received prior to 
establishing a request protocol based connection.... a pass-through class to which additional 
packets are assigned and received additional packets are forwarded even if a number of packets 
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forwarded from the class of their associated request packets has reached a maximum count" in 
page 812. 

In response to applicant's argument, the examiner respectfully disagrees with 
argument above. 

In response to applicant's arguments against the references individually, one cannot 
show nonobviousness by attacking references individually where the rejections are based on 
combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re 
Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). In this case, the combined system 
of Olsson, Barach and Valencia discloses the entire claimed invention, and the rejection based on 
the combined system, as detailed below. 

Regarding claims 2-16, 18-32, the applicant argued that, ". . the cited references 
(Choudhury nor Suzuki) fail to disclose a count of active connection reqeusts for which 
connection have not been established. . ." in page 11-12. 

In response to applicant's argument, the examiner respectfully disagrees with the 
argument above. 

Choudhury discloses wherein the packet is forwarded only if a count of active connection 
packets has not reached a second maximum limit (see FIG. 2, the packet is forward when a 
count/number of active packets has not reach the limit/size/threshold of underutilized queue 30c; 
see col. 4, line 1-1. 

In response to applicant's arguments against the references individually, one cannot 
show nonobviousness by attacking references individually where the rejections are based on 
combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re 
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Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). In this case, the combined system 
of Olsson, Barach, Valencia and Choudhury discloses the entire claimed invention, and the 
rejection based on the combined system, as detailed below. 

Suzuki discloses wherein the packet is forwarded only if a count of active connection 
packets has not reached a second maximum limit (see FIG. 3, comparing the packet according 
secondary Thresholds, Thr2-Thr4, before forwarding the packets; see col. 4, line 25-64; see col. 
8, line 1-5,50-60). 

In response to applicant's arguments against the references individually, one cannot 
show nonobviousness by attacking references individually where the rejections are based on 
combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re 
Merck & Co., 800 F.2d 1091, 23 1 USPQ 375 (Fed. Cir. 1986). In this case, the combined system 
of Olsson, Barach, Valencia and Suzuki discloses the entire claimed invention, and the rejection 
based on the combined system, as detailed below. 



Double Patenting 

2. The nonstatutory double patenting rejection is based on a judicially created doctrine 
grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or 
improper timewise extension of the "right to exclude" granted by a patent and to prevent possible 
harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection 
is appropriate where the conflicting claims are not identical, but at least one examined 
application claim is not patentably distinct from the reference claim(s) because the examined 
application claim is either anticipated by, or would have been obvious over, the reference 
claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re 
Goodman, 1 1 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 
USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re 
Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 
USPQ 644 (CCPA 1969). 
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A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may 
be used to overcome an actual or provisional rejection based on a nonstatutory double patenting 
ground provided the conflicting application or patent either is shown to be commonly owned 
with this application, or claims an invention made as a result of activities undertaken within the 
scope of a joint research agreement. 

Effective January 1, 1994, a registered attorney or agent of record may sign a terminal 
disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 
3.73(b). 

3. Claims 1-4, 17-20, and 33 are provisionally rejected on the ground of nonstatutory 
obviousness-type double patenting as being unpatentable over claims 1,2,4-6,19,20,22- 
24,35,36,39 and 40 of copending Application No. 10/642,042 (hereinafter refers to Narayana) in 
view of Barach (US007289441B1) and Henriques (US 2003/0198183). 

Regarding Claim 1 of the instant application, Narayana discloses a method for 
managing connections in a network comprising (see, claim 1, line 1-2, and claim 36, line 1-2): 

receiving a packet for establishing a protocol-based connection (see, claim 1, line 3, 
claim 36, line 3); 

assigning the packet to a selected one of a plurality of classes (see claim 1, line 4-5, claim 
36, line 4-5); 

forwarding the packet if the number of packets forwarded from the selected class in a 
predetermined time interval has not reached a first maximum count (see claim 1, line 6-9, claim 
36, line 8-10); and 

dropping the packet if the number of packets forwarded from the selected class in the 
predetermined time interval has reached the first maximum count (see claim 1, lines 11-12, claim 
36, line 11-12). 
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Narayana does not explicitly disclose "a request packet" and "a protocol of the requested 
connection". 

Barach discloses a method for managing connections (see FIG. I, 2, methods FIG. 6, 
Intermediate network node 200 processing/performing the steps/method controlling/managing 
routing/forwarding connections/sessions) in a network (see FIG. 1, 2, control/managing 
routing/forwarding in a network 100; see col. 4, line 46 to col. 5, line 15) comprising: 

receiving a request packet associated for establishing a protocol-based connection (see 
FIG. 2, see FIG. 6, Step 610; receiving PADI/ICRQ request packet/PDU for establishing 
PPPoE/L2TP protocol based connection; see col. 5, line 28-46; see col. 6, line 20-30; see col. 8, 
line 35-45); 

forwarding the request packet if a number of request packets forwarded in a 
predetermined time interval (see FIG. 3, 4, FIG. 6, step 630, 640, when the number/count 
PADI/ICRQ request packet/PDU packets sent in predetermined time/clock interval; note 
that PDUs that cause to determine whether to route/forward or drop the connection are 
request PDUs) has not reached a first maximum count (see FIG. 3, FIG. 6, step 630, 640; is 
within the maximum/allowable predetermine number of time/clock); see col. 6, line 36 to col. 7, 
line 65; see col. 8, line 35-67); and 

dropping the packet if number of request packets forwarded from the class in the 
predetermined time interval has reached the first maximum count (see FIG. 3, 4; FIG. 6, step 
650, 660; drop the PADI/ICRQ request packet/PDU when the number/count of request 
packets/PDUs sent is greater than the allowable/acceptable predetermine time/clock interval; see 
col. 6, line 36 to col. 7, line 65; see col. 8, line 35-67); 
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receiving an addition packet associated with the request packet prior to establishing the 
protocol-based connection (see FIG. 3, 4; FIG. 6, step 650, 660; subsequent/next 
packets/PDU that are associated/related to a first accepted and forwarded/routed 
PADI/ICRQ requested PDU before establishing the connection; note that plurality of PDUs 
are received and routed/forward for connection(s); see col. 6, line 36 to col. 7, line 65; see 
col. 8, line 35-65); 

forwarding the additional packet (see col. 6, line 36 to col. 7, line 65; see col. 8, line 35- 
6; see FIG. 3, 4, FIG. 6, step 630, 640; subsequent/next packets/PDU are also forwarded ). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a request packet" and "a protocol of the requested 
connection" as taught by Barach in the system of Narayana, so that it would provide more 
efficiently utilization of network resources which decreasing its latency of establishing a large 
number of new communication session as suggested by Barach; see Barach col. 3, line 1-30. 

Neither Narayana nor Barach explicitly discloses forwarding "even if the first maximum 
count has been reached". 

However, Henriques discloses receiving an additional packet associated with the request 
packet prior to establishing the protocol-based connection (see FIG. 8, steps 41,61,81, arriving 
other/next/additional packet associated with request/query packet before setting/establishing the 
connection with available resources; see page 5, paragraph 48-52); 

assigning the additional packet to a pass-through class if the packet is forwarded (see 
FIG. 8, Step 87, 89, 91; assigning/allocation the other/next/additional packet to a transmit 
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class/set/group if the packet is to be transmitted with available resources; see page 5, paragraph 
48-52); 

forwarding the additional packet from the pass-through class even if the first maximum 
count has been reached (see FIG. 8, Step 87, 89, 91; transmitting the other/next/additional packet 
from passing-through class/set/group (since the system is congestion mode, yet it is passing 
through the packet to transmit) even if the maximum/acceptable threshold/count has been exceed 
(which cases the system to go into congestion mode); see page 5, paragraph 48-52). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide assigning "if the packet is forwarded" and forwarding "even if 
the first maximum count has been reached" as taught by Henriques, in the combined system of 
Narayana and Barach, so that it would provide efficient policing function for a packet network; 
see Henriques page 2, paragraph 15-16. 

Regarding Claim 2 of the instant application, Narayana discloses wherein the first 
maximum count is adjustable to effectuate different rates of packet forwarding for the selected 
class (see claim 6). 

Regarding Claim 3 of the instant application, Narayana discloses wherein the 
predetermined time interval is adjustable to effectuate different rates of packet forwarding for the 
selected class (see claim 2 and 4). 

Regarding Claim 4 of the instant application, Narayana discloses wherein a counter 
associated with the selected class is used to determine whether number of packets forwarded 
from the selected class in the predetermined time interval has reached the first maximum count 
(see claim 1 and 5). 
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Regarding Claim 17 of the instant application, Narayana discloses an apparatus for 
managing connections in a network comprising (see claim 19, line 1-2, claim 39, line 1-2): 

a control plane operable to process requests for protocol-based connection (see claim 19, 
line 15-17); and 

a data plane operative to receive a packet associated with a request for a protocol-based 
connection (see claim 19, line 4-6, claim 19, line 3), 

assign the packet to a selected one of a plurality of classes (see claim 19, line 6-7, claim 
39, line 5-7), 

forward the packet to the control plane if the number of packets forwarded from the 
selected class in a predetermined time interval has not reached a first maximum count (see claim 
19, line 9-11, claim 39, line 12-14), and 

drop the packet if the number of packets forwarded from the selected class in the 
predetermined time interval has reached the first maximum count (see Narayana claim 19, line 
12-14, claim 39). 

Narayana does not explicitly disclose "a request packet" and "a protocol of the requested 
connection". 

However, Barach discloses an apparatus (see FIG. 1, 2, Intermediate network node 200) 
for managing connections in a network (see FIG. 1, 2, control/managing routing/forwarding in a 
network 100; see col. 4, line 46 to col. 5, line 15) comprising: 

a control plane (see FIG. 2, a control plane includes entities used to manage/control 
operation of the node (e.g. a combined system of logic 220, route processor 270, RP module 260, 
system controller 280)) operative to process requests for protocol-based connection (see FIG. 2, 
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processes requests (i.e. PPPoE Active Discovery Initiation (PAD I) and Incoming Call Request 
(ICRQ)) for routing/forwarding for PPPoE/L2TP protocol based connection; see col. 2, line 4- 
24; see col. 5, line 29-64; see col. 6, line 20-30); and 

a data plane (see FIG. 2, a data plane includes components used to retrieve data packets 
(e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 230, 
buffer 240)) operative to: 

receive a request packet for establishing a protocol-based connection (see FIG. 2, see 
FIG. 6, Step 610; receiving PADI/ICRQ request packet/PDU for establishing PPPoE/L2TP 
protocol based connection; see col. 5, line 28-46; see col. 6, line 20-30; see col. 8, line 35-45), 

forward the request packet to the control plane (see FIG. 2, forward PADI/ICRQ request 
packet/PDU to the control plane; see FIG. 6, Step 630, 640) to if the number of packets 
forwarded in a predetermined time interval (see FIG. 3, 4, FIG. 6, step 630, 640, when the 
number/count PADI/ICRQ request packet/PDU packets sent in predetermined time/clock 
interval; note that PDUs that cause to determine whether to route/forward or drop the 
connection are request PDUs) has not reached a first maximum count (see FIG. 3, FIG. 6, step 
630, 640; is within the maximum/allowable predetermine number of time/clock); see col. 6, line 
36 to col. 7, line 65; see col. 8, line 35-67); 

drop the packet if the number of request packets forwarded in the predetermined time 
interval has reached the first maximum count (see FIG. 3, 4; FIG. 6, step 650, 660; drop the 
PADI/ICRQ request packet/PDU when the number/count of packets sent is greater than the 
allowable/acceptable predetermine time/clock interval; see col. 6, line 36 to col. 7, line 65; see 
col. 8, line 35-67); 
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receiving an addition packet associated with the request packet prior to establishing the 
protocol-based connection (see FIG. 3, 4; FIG. 6, step 650, 660; subsequent/next 
packets/PDU that are associated/related to a first accepted and forwarded/routed 
PADI/ICRQ requested PDU before establishing the connection; note that plurality of PDUs 
are received and routed/forward for connection(s); see col. 6, line 36 to col. 7, line 65; see 
col. 8, line 35-65); 

forwarding the additional packet (see col. 6, line 36 to col. 7, line 65; see col. 8, line 35- 
6; see FIG. 3, 4, FIG. 6, step 630, 640; subsequent/next packets/PDU are also forwarded ). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a request packet" and "a protocol of the requested 
connection" as taught by Barach in the system of Narayana, so that it would provide more 
efficiently utilization of network resources which decreasing its latency of establishing a large 
number of new communication session as suggested by Barach; see Barach col. 3, line 1-30. 

Neither Narayana nor Barach explicitly discloses forwarding "even if the first maximum 
count has been reached". 

However, Henriques discloses receiving an additional packet associated with the request 
packet prior to establishing the protocol-based connection (see FIG. 8, steps 41,61,81, arriving 
other/next/additional packet associated with request/query packet before setting/establishing the 
connection with available resources; see page 5, paragraph 48-52); 

assigning the additional packet to a pass-through class if the packet is forwarded (see 
FIG. 8, Step 87, 89, 91; assigning/allocation the other/next/additional packet to a transmit 
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class/set/group if the packet is to be transmitted with available resources; see page 5, paragraph 
48-52); 

forwarding the additional packet from the pass-through class even if the first maximum 
count has been reached (see FIG. 8, Step 87, 89, 91; transmitting the other/next/additional packet 
from passing-through class/set/group (since the system is congestion mode, yet it is passing 
through the packet to transmit) even if the maximum/acceptable threshold/count has been exceed 
(which cases the system to go into congestion mode); see page 5, paragraph 48-52). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide assigning "if the packet is forwarded" and forwarding "even if 
the first maximum count has been reached" as taught by Henriques, in the combined system of 
Narayana and Barach, so that it would provide efficient policing function for a packet network; 
see Henriques page 2, paragraph 15-16. 

Regarding Claim 18 of the instant application, Narayana discloses wherein the first 
maximum count is adjustable to effectuate different rates of packet forwarding for the selected 
class (see claim 24). 

Regarding Claim 19 of the instant application, Narayana discloses wherein the 
predetermined time interval is adjustable to effectuate different rates of packet forwarding for the 
selected class (see claim 20 and 22). 

Regarding Claim 20 of the instant application, Narayana discloses wherein a counter 
associated with the selected class is used to determine whether number of packets forwarded 
from the selected class in the predetermined time interval has reached the first maximum count 
(see claim 19 and 23). 
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Regarding Claim 33 of the instant application, Narayana discloses a system for 
managing connections in a network (see claim 35 and 40) comprising: 

means for receiving a packet associated with a request for a protocol-based connection 
(see Narayana claim 35 and 40); 

means for assigning the packet to a selected one of a plurality of classes (see Narayana 
claim 35 and 40); 

means for forwarding the packet if the number of packets forwarded from the selected 
class in a predetermined time interval has not reached a first maximum count (see Narayana 
claim 35 and 40); and 

means for dropping the packet if the number of packets forwarded from the selected class 
in the predetermined time interval has reached the first maximum count (see Narayana claim 35 
and 40). 

Narayana does not explicitly disclose "a request packet" and "a protocol of the requested 
connection". 

Barach discloses a system (see FIG. 1, 2, Intermediate network node 200) for managing 
connections in a network (see FIG. 1, 2, control/managing routing/forwarding in a network 100; 
see col. 4, line 46 to col. 5, line 15) comprising: 

means for receiving (see FIG. 2, a data plane includes components used to retrieve data 
packets (e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 
230, buffer 240)) a request packet associated for establishing a protocol-based connection (see 
FIG. 2, see FIG. 6, Step 610; receiving PADWCRQ request packet/PDU for establishing 
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PPPoE/L2TP protocol based connection; see col. 5, line 28-46; see col. 6, line 20-30; see col. 8, 
line 35-45); 

means for forwarding (see FIG. 2, a data plane includes components used to retrieve data 
packets (e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 
230, buffer 240)) the request packet if number of request packets forwarded from the selected 
class in a predetermined time interval (see FIG. 3, 4, FIG. 6, step 630, 640, when the 
number/count PADI/ICRQ request packet/PDU packets sent in predetermined time/clock 
interval; note that PDUs that cause to determine whether to route/forward or drop the 
connection are request PDUs) has not reached a first maximum count (see FIG. 3, FIG. 6, step 
630, 640; is within the maximum/allowable predetermine number of time/clock); see col. 6, line 
36 to col. 7, line 65; see col. 8, line 35-67); and 

means for dropping (see FIG. 2, a data plane includes components used to retrieve data 
packets (e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 
230, buffer 240)) the packet if number of request packets forwarded from the class in the 
predetermined time interval has reached the first maximum count (see FIG. 3, 4; FIG. 6, step 
650, 660; drop the PADI/ICRQ request packet/PDU when the number/count of request packets 
sent is greater than the allowable/acceptable predetermine time/clock interval; see col. 6, line 36 
to col. 7, line 65; see col. 8, line 35-67); 

means for receiving an addition packet associated with the request packet prior to 
establishing the protocol-based connection (see FIG. 3, 4; FIG. 6, step 650, 660; 
subsequent/next packets/PDU that are associated/related to a first accepted and 
forwarded/routed PADI/ICRQ requested PDU before establishing the connection; note 
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that plurality of PDUs are received and routed/forward for connection(s); see col. 6, line 36 
to col. 7, line 65; see col. 8, line 35-65); 

means for forwarding the additional packet (see col. 6, line 36 to col. 7, line 65; see col. 
8, line 35-6; see FIG. 3, 4, FIG. 6, step 630, 640; subsequent/next packets/PDU are also 
forwarded ). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a request packet" and "a protocol of the requested 
connection" as taught by Barach in the system of Olsson, so that it would provide more 
efficiently utilization of network resources which decreasing its latency of establishing a large 
number of new communication session as suggested by Barach; see Barach col. 3, line 1-30. 

Neither Narayana nor Barach explicitly discloses forwarding "even if the first maximum 
count has been reached". 

However, Henriques discloses means for receiving an additional packet associated with 
the request packet prior to establishing the protocol-based connection (see FIG. 8, steps 41,61, 
81, arriving other/next/additional packet associated with request/query packet before 
setting/establishing the connection with available resources; see page 5, paragraph 48-52); 

means for assigning the additional packet to a pass-through class if the packet is 
forwarded (see FIG. 8, Step 87, 89, 91; assigning/allocation the other/next/additional packet to a 
transmit class/set/group if the packet is to be transmitted with available resources; see page 5, 
paragraph 48-52); 

means for forwarding the additional packet from the pass-through class even if the first 
maximum count has been reached (see FIG. 8, Step 87, 89, 91; transmitting the 
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other/next/additional packet from passing-through class/set/group (since the system is congestion 
mode, yet it is passing through the packet to transmit) even if the maximum/acceptable 
threshold/count has been exceed (which cases the system to go into congestion mode); see page 
5, paragraph 48-52). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide assigning "if the packet is forwarded" and forwarding "even if 
the first maximum count has been reached" as taught by Henriques, in the combined system of 
Narayana and Barach, so that it would provide efficient policing function for a packet network; 
see Henriques page 2, paragraph 15-16. 

This is a provisional obviousness-type double patenting rejection because the conflicting 
claims have not in fact been patented. 

Claim Rejections - 35 USC § 103 

4. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

5. Claim 1,17, and 33 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Barach (US007289441B1) in view of Archilles (US006977894B1) and Henriques (US 
2003/0198183). 
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Regarding Claim 1, Barach discloses a method for managing connections (see FIG. 1, 2, 
methods FIG. 6, Intermediate network node 200 processing/performing the steps/method 
controlling/managing routing/forwarding connections/sessions) in a network (see FIG. 1, 2, 
control/managing routing/forwarding in a network 100; see col. 4, line 46 to col. 5, line 15) 
comprising: 

receiving a request packet associated for establishing a protocol-based connection (see 
FIG. 2, see FIG. 6, Step 610; receiving PADI/ICRQ request packet/PDU for establishing 
PPPoE/L2TP protocol based connection; see col. 5, line 28-46; see col. 6, line 20-30; see col. 8, 
line 35-45); 

forwarding the request packet if a number of request packets forwarded in a 
predetermined time interval (see FIG. 3, 4, FIG. 6, step 630, 640, when the number/count 
PADI/ICRQ request packet/PDU packets sent in predetermined time/clock interval; note 
that PDUs that cause to determine whether to route/forward or drop the connection are 
request PDUs) has not reached a first maximum count (see FIG. 3, FIG. 6, step 630, 640; is 
within the maximum/allowable predetermine number of time/clock); see col. 6, line 36 to col. 7, 
line 65; see col. 8, line 35-67); and 

dropping the packet if number of request packets forwarded from the class in the 
predetermined time interval has reached the first maximum count (see FIG. 3, 4; FIG. 6, step 
650, 660; drop the PADI/ICRQ request packet/PDU when the number/count of request 
packets/PDUs sent is greater than the allowable/acceptable predetermine time/clock interval; see 
col. 6, line 36 to col. 7, line 65; see col. 8, line 35-67); 
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receiving an addition packet associated with the request packet prior to establishing the 
protocol-based connection (see FIG. 3, 4; FIG. 6, step 650, 660; subsequent/next 
packets/PDU that are associated/related to a first accepted and forwarded/routed 
PADI/ICRQ requested PDU before establishing the connection; note that plurality of PDUs 
are received and routed/forward for connection(s); see col. 6, line 36 to col. 7, line 65; see 
col. 8, line 35-65); 

forwarding the additional packet (see col. 6, line 36 to col. 7, line 65; see col. 8, line 35- 
6; see FIG. 3, 4, FIG. 6, step 630, 640; subsequent/next packets/PDU are also forwarded ). 

Barach does not explicitly disclose "assign the packet to a selected one of a plurality of 
classes", forwarded from "the selected class", "assigning the additional packet to a pass-through 
class", and forwarding from "the pass-through class". 

However, Archilles discloses receiving a packet for establishing a protocol-based 
connection (see FIG. 1, receiving packet that request for routing/forwarding for L3 connection; 
see col. 3, line 1-30), 

assigning the packet to a selected one of a plurality of classes based upon a protocol of 
the request (see FIG. 1, classifying each packet to one internal service classes (ISC) of ISCs (e.g. 
ISC=1) according to L3/L2 protocol connection of the request; see col. 4, line 5 to col. 5, line 
65), 

forwarding the packet (see FIG. 1, forward the packets to a combined system of CXP 127 
and DMA 135) if the number of packets forwarded from the selected class (see FIG. 1 , when the 
number of packets from the ISC class) in a predetermined time interval (see FIG. 1, 4A, 5, within 
watermark traffic rate/time or threshold ICR rate/time; note that rate is defined as number/time 
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packets per time, and thus when comparing to watermark rate); see col. 3, line 30 to col. 5, line 
65) has not reached a first maximum count (see FIG. 1, 4A, S 41 1; FIG. 5, S 507 with No; see 
col. 3, line 30 to col. 5, line 65; forwarding the packets when the number of packets within the of 
the watermark traffic time/rate rate or threshold ICR time/rate has not exceed); 

dropping the packet if the number of packets forwarded from the selected class in the 
predetermined time interval has reached the first maximum count (see FIG. 1, 4A, S 409; FIG. 5, 
S 509; see col. 3, line 30 to col. 5, line 65; drop the packets when the number/count of packets 
within the watermark traffic time/rate rate or threshold ICR time/rate has not exceed); 

assigning the additional packet to a pass-through class if the packet is forwarded (see 
FIG. 1, classifying next/subsequent packet to other internal service classes (ISC) of ISCs 
(e.g. ISC=2) to be routed/passing-through according to L3/L2 protocol connection of the 
request if the packet is to be routed/forwarded); see col. 4, line 5 to col. 5, line 65); 

forwarding the additional packet from the pass-through class (see FIG. 1, forward the 
next/sequent packets to a combined system of CXP 127 and DMA 135 when the number of 
packets from the ISC class; see col. 3, line 30 to col. 5, line 65). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "assign the packet to a selected one of a plurality of classes", 
forwarded from "the selected class", "assigning the additional packet to a pass-through class", 
and forwarding from "the pass-through class" as taught by Archilles in the system of Barach, so 
that it would provide stable operation, service differentiation, and superior reliability as 
suggested by Archilles; see Archilles col. 1, line 65 to col. 2, line 10. 



Application/Control Number: Page 20 

10/646,617 

Art Unit: 2416 

Neither Barach nor Archilles explicitly discloses assigning "if the packet is forwarded" 
and forwarding "even if the first maximum count has been reached". 

However, Henriques discloses receiving an additional packet associated with the request 
packet prior to establishing the protocol-based connection (see FIG. 8, steps 41,61,81, arriving 
other/next/additional packet associated with request/query packet before setting/establishing the 
connection with available resources; see page 5, paragraph 48-52); 

assigning the additional packet to a pass-through class if the packet is forwarded (see 
FIG. 8, Step 87, 89, 91; assigning/allocation the other/next/additional packet to a transmit 
class/set/group if the packet is to be transmitted with available resources; see page 5, paragraph 
48-52); 

forwarding the additional packet from the pass-through class even if the first maximum 
count has been reached (see FIG. 8, Step 87, 89, 91; transmitting the other/next/additional packet 
from passing-through class/set/group (since the system is congestion mode, yet it is passing 
through the packet to transmit) even if the maximum/acceptable threshold/count has been exceed 
(which cases the system to go into congestion mode); see page 5, paragraph 48-52). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide assigning "if the packet is forwarded" and forwarding "even if 
the first maximum count has been reached" as taught by Henriques, in the combined system of 
Barach and Archilles, so that it would provide efficient policing function for a packet network; 
see Henriques page 2, paragraph 15-16. 
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Regarding Claim 17, Barach discloses an apparatus (see FIG. 1, 2, Intermediate network 
node 200) for managing connections in a network (see FIG. 1, 2, control/managing 
routing/forwarding in a network 100; see col. 4, line 46 to col. 5, line 15) comprising: 

a control plane (see FIG. 2, a control plane includes entities used to manage/control 
operation of the node (e.g. a combined system of logic 220, route processor 270, RP module 260, 
system controller 280)) operative to process requests for protocol-based connection (see FIG. 2, 
processes requests (i.e. PPPoE Active Discovery Initiation (PADI) and Incoming Call Request 
(ICRQ)) for routing/forwarding for PPPoE/L2TP protocol based connection; see col. 2, line 4- 
24; see col. 5, line 29-64; see col. 6, line 20-30); and 

a data plane (see FIG. 2, a data plane includes components used to retrieve data packets 
(e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 230, 
buffer 240)) operative to: 

receive a request packet for establishing a protocol-based connection (see FIG. 2, see 
FIG. 6, Step 610; receiving PADI/ICRQ request packet/PDU for establishing PPPoE/L2TP 
protocol based connection; see col. 5, line 28-46; see col. 6, line 20-30; see col. 8, line 35-45), 

forward the request packet to the control plane (see FIG. 2, forward PADI/ICRQ request 
packet/PDU to the control plane; see FIG. 6, Step 630, 640) to if the number of request packets 
forwarded in a predetermined time interval (see FIG. 3, 4, FIG. 6, step 630, 640, when the 
number/count PADI/ICRQ request packet/PDU packets sent in predetermined time/clock 
interval; note that PDUs that cause to determine whether to route/forward or drop the 
connection are request PDUs) has not reached a first maximum count (see FIG. 3, FIG. 6, step 
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630, 640; is within the maximum/allowable predetermine number of time/clock); see col. 6, line 
36 to col. 7, line 65; see col. 8, line 35-67); 

drop the packet if the number of request packets forwarded in the predetermined time 
interval has reached the first maximum count (see FIG. 3, 4; FIG. 6, step 650, 660; drop the 
PADI/ICRQ request packet/PDU when the number/count of request packets/PDUs sent is 
greater than the allowable/acceptable predetermine time/clock interval; see col. 6, line 36 to 
col. 7, line 65; see col. 8, line 35-67); 

receiving an addition packet associated with the request packet prior to establishing the 
protocol-based connection (see FIG. 3, 4; FIG. 6, step 650, 660; subsequent/next 
packets/PDU that are associated/related to a first accepted and forwarded/routed 
PADI/ICRQ requested PDU before establishing the connection; note that plurality of PDUs 
are received and routed/forward for connection(s); see col. 6, line 36 to col. 7, line 65; see 
col. 8, line 35-65); 

forwarding the additional packet (see col. 6, line 36 to col. 7, line 65; see col. 8, line 35- 
6; see FIG. 3, 4, FIG. 6, step 630, 640; subsequent/next packets/PDU are also forwarded ). 

Barach does not explicitly disclose "assign the packet to a selected one of a plurality of 
classes", forwarded from "the selected class", "assigning the additional packet to a pass-through 
class", and forwarding from "the pass-through class". 

However, Archilles discloses an apparatus or system (see FIG. 1, L3 apparatus) 
processing a method (see FIG. 4a,5, method) for managing connections in a network (see FIG. 1, 
control/managing routing/forwarding in a computer network; see col. 1, line 20-30; see col. 2, 
line 65-67) comprising: 
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a control plane (see FIG. 1, a combined system of Router Switch processor CXP 127 and 
DMA controller 135) operative to process requests for protocol-based connection (see FIG. 1, 
processes packets that request for routing/forwarding for Layer 3 protocol (L3) connection; see 
col. 3, line 1-30); and 

a data plane (see FIG. 1, a combined system of packet Rx 1 13, descriptor 115, buffer 
memory 119, output queue selection 113, and outbound queue 107) operative to: 

receive a packet for establishing a protocol-based connection (see FIG. 1, receiving 
packet that request for routing/forwarding for L3 connection; see col. 3, line 1-30), 

assign the packet to a selected one of a plurality of classes based upon a protocol of the 
request (see FIG. 1, classifying each packet to one internal service classes (ISC) of ISCs 
according to L3/L2 protocol connection of the request; see col. 4, line 5 to col. 5, line 65), 

forward the packet to the control plane (see FIG. 1, forward the packets to a combined 
system of CXP 127 and DMA 135) to if the number of packets forwarded from the selected class 
(see FIG. 1, when the number of packets from the ISC class) in a predetermined time interval 
(see FIG. 1, 4A, 5, within watermark traffic rate/time or threshold ICR rate/time; note that rate is 
defined as number/time packets per time, and thus when comparing to watermark rate); see col. 
3, line 30 to col. 5, line 65) has not reached a first maximum count (see FIG. 1, 4A, S 41 1; FIG. 
5, S 507 with No; see col. 3, line 30 to col. 5, line 65; forwarding the packets when the number 
of packets within the of the watermark traffic time/rate rate or threshold ICR time/rate has not 
exceed); 

drop the packet if the number of packets forwarded from the selected class in the 
predetermined time interval has reached the first maximum count (see FIG. 1, 4A, S 409; FIG. 5, 
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S 509; see col. 3, line 30 to col. 5, line 65; drop the packets when the number/count of packets 
within the watermark traffic time/rate rate or threshold ICR time/rate has not exceed); 

assigning the additional packet to a pass-through class if the packet is forwarded (see 
FIG. 1, classifying next/subsequent packet to other internal service classes (ISC) of ISCs 
(e.g. ISC=2) to be routed/passing-through according to L3/L2 protocol connection of the 
request if the packet is to be routed/forwarded); see col. 4, line 5 to col. 5, line 65); 

forwarding the additional packet from the pass-through class (see FIG. 1, forward the 
next/sequent packets to a combined system of CXP 127 and DMA 135 when the number of 
packets from the ISC class; see col. 3, line 30 to col. 5, line 65). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "assign the packet to a selected one of a plurality of classes", 
forwarded from "the selected class", "assigning the additional packet to a pass-through class", 
and forwarding from "the pass-through class" as taught by Archilles in the system of Barach, so 
that it would provide stable operation, service differentiation, and superior reliability as 
suggested by Archilles; see Archilles col. 1, line 65 to col. 2, line 10. 

Neither Barach nor Archilles explicitly discloses assigning "if the packet is forwarded" 
and forwarding "even if the first maximum count has been reached". 

However, Henriques discloses receiving an additional packet associated with the request 
packet prior to establishing the protocol-based connection (see FIG. 8, steps 41,61,81, arriving 
other/next/additional packet associated with request/query packet before setting/establishing the 
connection with available resources; see page 5, paragraph 48-52); 
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assigning the additional packet to a pass-through class if the packet is forwarded (see 
FIG. 8, Step 87, 89, 91; assigning/allocation the other/next/additional packet to a transmit 
class/set/group if the packet is to be transmitted with available resources; see page 5, paragraph 
48-52); 

forwarding the additional packet from the pass-through class even if the first maximum 
count has been reached (see FIG. 8, Step 87, 89, 91; transmitting the other/next/additional packet 
from passing-through class/set/group (since the system is congestion mode, yet it is passing 
through the packet to transmit) even if the maximum/acceptable threshold/count has been exceed 
(which cases the system to go into congestion mode); see page 5, paragraph 48-52). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide assigning "if the packet is forwarded" and forwarding "even if 
the first maximum count has been reached" as taught by Henriques, in the combined system of 
Barach and Archilles, so that it would provide efficient policing function for a packet network; 
see Henriques page 2, paragraph 15-16. 

Regarding Claim 33, Barach discloses a system (see FIG. 1, 2, Intermediate network 
node 200) for managing connections in a network (see FIG. 1, 2, control/managing 
routing/forwarding in a network 100; see col. 4, line 46 to col. 5, line 15) comprising: 

means for receiving (see FIG. 2, a data plane includes components used to retrieve data 
packets (e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 
230, buffer 240)) a request packet associated for establishing a protocol-based connection (see 
FIG. 2, see FIG. 6, Step 610; receiving PADWCRQ request packet/PDU for establishing 
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PPPoE/L2TP protocol based connection; see col. 5, line 28-46; see col. 6, line 20-30; see col. 8, 
line 35-45); 

means for forwarding (see FIG. 2, a data plane includes components used to retrieve data 
packets (e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 
230, buffer 240)) the request packet if number of request packets forwarded from the selected 
class in a predetermined time interval (see FIG. 3, 4, FIG. 6, step 630, 640, when the 
number/count PADI/ICRQ request packet/PDU packets sent in predetermined time/clock 
interval; note that PDUs that cause to determine whether to route/forward or drop the 
connection are request PDUs) has not reached a first maximum count (see FIG. 3, FIG. 6, step 
630, 640; is within the maximum/allowable predetermine number of time/clock); see col. 6, line 
36 to col. 7, line 65; see col. 8, line 35-67); and 

means for dropping (see FIG. 2, a data plane includes components used to retrieve data 
packets (e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 
230, buffer 240)) the packet if number of request packets forwarded from the class in the 
predetermined time interval has reached the first maximum count (see FIG. 3, 4; FIG. 6, step 
650, 660; drop the PADI/ICRQ request packet/PDU when the number/count of request 
packets/PDUs sent is greater than the allowable/acceptable predetermine time/clock 
interval; see col. 6, line 36 to col. 7, line 65; see col. 8, line 35-67); 

means for assigning the additional packet to a pass-through class if the packet is 
forwarded (see FIG. 1, classifying next/subsequent packet to other internal service classes 
(ISC) of ISCs (e.g. ISC=2) to be routed/passing-through according to L3/L2 protocol 
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connection of the request if the packet is to be routed/forwarded); see col. 4, line 5 to col. 5, 
line 65); 

means for forwarding the additional packet from the pass-through class (see FIG. 1, 
forward the next/sequent packets to a combined system of CXP 127 and DMA 135 when 
the number of packets from the ISC class; see col. 3, line 30 to col. 5, line 65). 

Barach does not explicitly disclose "assign the packet to a selected one of a plurality of 
classes", forwarded from "the selected class", "assigning the additional packet to a pass-through 
class", and forwarding from "the pass-through class". 

However, Archilles discloses an apparatus or system (see FIG. 1, L3 apparatus) 
processing a method (see FIG. 4a,5, method) for managing connections in a network (see FIG. 1, 
control/managing routing/forwarding in a computer network; see col. 1, line 20-30; see col. 2, 
line 65-67) comprising: 

means for receiving (see FIG. 1, a combined system of packet Rx 1 13, descriptor 115, 
buffer memory 119, output queue selection 1 13, and outbound queue 107) a packet for 
establishing a protocol-based connection (see FIG. 1, receiving packet that request for 
routing/forwarding for L3 connection; see col. 3, line 1-30), 

means for assigning (see FIG. 1, a combined system of packet Rx 1 13, descriptor 115, 
buffer memory 119, output queue selection 1 13, and outbound queue 107) the packet to a 
selected one of a plurality of classes based upon a protocol of the request (see FIG. 1, classifying 
each packet to one internal service classes (ISC) of ISCs according to L3/L2 protocol connection 
of the request; see col. 4, line 5 to col. 5, line 65), 
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means for forwarding (see FIG. 1, a combined system of packet Rx 1 13, descriptor 115, 
buffer memory 119, output queue selection 113, and outbound queue 107) the packet to the 
control plane (see FIG. 1, forward the packets to a combined system of CXP 127 and DMA 135) 
to if the number of packets forwarded from the selected class (see FIG. 1, when the number of 
packets from the ISC class) in a predetermined time interval (see FIG. 1, 4A, 5, within 
watermark traffic rate/time or threshold ICR rate/time; note that rate is defined as number/time 
packets per time, and thus when comparing to watermark rate); see col. 3, line 30 to col. 5, line 
65) has not reached a first maximum count (see FIG. 1, 4A, S 41 1; FIG. 5, S 507 with No; see 
col. 3, line 30 to col. 5, line 65; forwarding the packets when the number of packets within the of 
the watermark traffic time/rate rate or threshold ICR time/rate has not exceed); 

means for dropping (see FIG. 1, a combined system of packet Rx 113, descriptor 115, 
buffer memory 119, output queue selection 1 13, and outbound queue 107) the packet if the 
number of packets forwarded from the selected class in the predetermined time interval has 
reached the first maximum count (see FIG. 1, 4A, S 409; FIG. 5, S 509; see col. 3, line 30 to col. 
5, line 65; drop the packets when the number/count of packets within the watermark traffic 
time/rate rate or threshold ICR time/rate has not exceed); 

means for assigning the additional packet to a pass-through class if the packet is 
forwarded (see FIG. 1, classifying next/subsequent packet to other internal service classes 
(ISC) of ISCs (e.g. ISC=2) to be routed/passing-through according to L3/L2 protocol 
connection of the request if the packet is to be routed/forwarded); see col. 4, line 5 to col. 5, 
line 65); 



Application/Control Number: Page 29 

10/646,617 

Art Unit: 2416 

means for forwarding the additional packet from the pass-through class (see FIG. 1, 
forward the next/sequent packets to a combined system of CXP 127 and DMA 135 when 
the number of packets from the ISC class; see col. 3, line 30 to col. 5, line 65). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "assign the packet to a selected one of a plurality of classes" 
and "forwarded from the selected class" as taught by Archilles in the system of Barach, so that it 
would provide stable operation, service differentiation, and superior reliability as suggested by 
Archilles; see Archilles col. 1, line 65 to col. 2, line 10. 

Neither Barach nor Archilles explicitly discloses assigning "if the packet is forwarded" 
and forwarding "even if the first maximum count has been reached". 

However, Henriques discloses means for receiving an additional packet associated with 
the request packet prior to establishing the protocol-based connection (see FIG. 8, steps 41,61, 
81, arriving other/next/additional packet associated with request/query packet before 
setting/establishing the connection with available resources; see page 5, paragraph 48-52); 

means for assigning the additional packet to a pass-through class if the packet is 
forwarded (see FIG. 8, Step 87, 89, 91; assigning/allocation the other/next/additional packet to a 
transmit class/set/group if the packet is to be transmitted with available resources; see page 5, 
paragraph 48-52); 

means for forwarding the additional packet from the pass-through class even if the first 
maximum count has been reached (see FIG. 8, Step 87, 89, 91; transmitting the 
other/next/additional packet from passing-through class/set/group (since the system is congestion 
mode, yet it is passing through the packet to transmit) even if the maximum/acceptable 
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threshold/count has been exceed (which cases the system to go into congestion mode); see page 

5, paragraph 48-52). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide assigning "if the packet is forwarded" and forwarding "even if 
the first maximum count has been reached" as taught by Henriques, in the combined system of 
Barach and Archilles, so that it would provide efficient policing function for a packet network; 
see Henriques page 2, paragraph 15-16. 

6. Claims 1, 17, and 33 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Olsson (US006577596B1) in view of Barach and further in view of Henriques. 

Regarding Claim 1, Olsson discloses a method (see FIG. 2, node 200, see FIG. 3, node 
300, or see FIG. 6, node 600 processing the steps/methods) for managing connections in a 
network (see FIG. 2, 3, 6, control routing/forwarding in a exemplary PPP/IP network; see col. 5, 
line 66 to col. 6, line 10; see col. 7, line 46-67) comprising: 

receiving a packet for establishing a protocol-based connection (see FIG. 2, receiving 
packet 211/212/213 at node 200/300/600 for PPP/IP connection; see FIG. 3, receiving Packet 
315-318 at node 200/300/600 for PPP/IP for setting-up connection; see col. 6, line 63 to col. 7, 
line 16,25-45; see col. 11, line 45-49), 

assign the packet to a selected one of a plurality of classes based upon a protocol of the 
connection (see FIG. 2, 3, 6, different QoS classification queues D1-D4, or D1.D N , where Dl is 
for high QoS classification packets, and D N is lower QoS classification packets according to 
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PPP/IP protocol of the connection; see col. 6, line 64 to col. 7, line 35; see col. 8, line 17-23, 60- 
65; see col. 9, line 44-45; see col. 11, line 43-50), 

forward the packet to the control plane (see FIG. 6, forward the packets from D N queues 
to data link layer/plane 530) to if the number of packets forwarded from the selected class (see 
FIG. 6, when packets each D1.D N QoS class) in a predetermined time interval (see FIG. 2,3,6, 
within scheduled/allocated time; see col. 6, line 60-65; see col. 8, line 27-30,44-65; see col. 9, 
line 17-42; see col. 10, line 30-40) has not reached a first maximum count (see FIG. 2,3,6, the 
size of queue; see col. 11, line 44-46; forwarding the packets when the specific QoS class queue 
DnIs yet filled with packets); 

drop the packet if the number of packets forwarded from the selected class in the 
predetermined time interval has reached the first maximum count (see FIG. 2,3,6, discarding the 
packets when the specific QoS class queue D N in the scheduled/allocated time is full (i.e. 
reaching maximum packet number/count); see col. 11, line 35-55); 

receiving an addition packet associated with the packet prior to establishing the protocol- 
based connection (see FIG. 2, receiving subsequent/next packet 211/212/213 at node 
200/300/600 before setting up PPP/IP connection; see FIG. 3, receiving Packet 315-318 at 
node 200/300/600 for PPP/IP for setting-up connection; note that plurality of packets are 
received and routed/forward for connection(s); see col. 6, line 63 to col. 7, line 16,25-45; see 
col. 11, line 45-49); 

assigning the additional packet to a pass-through class if the packet is forwarded ( see 
FIG. 2, 3, 6, assigning next/subsequent packet with intermediate/pass-through class, that 
is, QoS class for neither high QoS or Lower QoS D2/D3 if the packet is forwarded/routed 
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for connection; see col. 6, line 64 to col. 7, line 35; see col. 8, line 17-23, 60-65; see col. 9, line 
44-45; see col. 11, line 43-50); 

forwarding the additional packet from the pass-through class ( see FIG. 6, forward the 
packets with intermediate/pass-through class from D 2 /3 queues to data link layer/plane 530; 
see col. 6, line 60-65; see col. 8, line 27-30,44-65; see col. 9, line 17-42; see col. 10, line 30-40). 

Olsson does not explicitly disclose "a request packet" and "a protocol of the requested 
connection". 

Barach discloses a method for managing connections (sec FIG. 1, 2, methods FIG. 6, 
Intermediate network node 200 processing/performing the steps/method controlling/managing 
routing/forwarding connections/sessions) in a network (see FIG. 1, 2, control/managing 
routing/forwarding in a network 100; see col. 4, line 46 to col. 5, line 15) comprising: 

receiving a request packet associated for establishing a protocol-based connection (see 
FIG. 2, see FIG. 6, Step 610; receiving PADI/ICRQ request packet/PDU for establishing 
PPPoE/L2TP protocol based connection; see col. 5, line 28-46; see col. 6, line 20-30; see col. 8, 
line 35-45); 

forwarding the request packet if a number of request packets forwarded in a 
predetermined time interval (see FIG. 3, 4, FIG. 6, step 630, 640, when the number/count 
PADI/ICRQ request packet/PDU packets sent in predetermined time/clock interval; note 
that PDUs that cause to determine whether to route/forward or drop the connection are 
request PDUs) has not reached a first maximum count (see FIG. 3, FIG. 6, step 630, 640; is 
within the maximum/allowable predetermine number of time/clock); see col. 6, line 36 to col. 7, 
line 65; see col. 8, line 35-67); and 
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dropping the packet if number of request packets forwarded from the class in the 
predetermined time interval has reached the first maximum count (see FIG. 3, 4; FIG. 6, step 
650, 660; drop the PADI/ICRQ request packet/PDU when the number/count of request 
packets/PDUs sent is greater than the allowable/acceptable predetermine time/clock interval; see 
col. 6, line 36 to col. 7, line 65; see col. 8, line 35-67); 

receiving an addition packet associated with the request packet prior to establishing the 
protocol-based connection (see FIG. 3, 4; FIG. 6, step 650, 660; subsequent/next 
packets/PDU that are associated/related to a first accepted and forwarded/routed 
PADI/ICRQ requested PDU before establishing the connection; note that plurality of PDUs 
are received and routed/forward for connection(s); see col. 6, line 36 to col. 7, line 65; see 
col. 8, line 35-65); 

forwarding the additional packet (see col. 6, line 36 to col. 7, line 65; see col. 8, line 35- 
6; see FIG. 3, 4, FIG. 6, step 630, 640; subsequent/next packets/PDU are also forwarded ). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a request packet" and "a protocol of the requested 
connection" as taught by Barach in the system of Olsson, so that it would provide more 
efficiently utilization of network resources which decreasing its latency of establishing a large 
number of new communication session as suggested by Barach; see Barach col. 3, line 1-30. 

Neither Olsson nor Barach explicitly discloses forwarding "even if the first maximum 
count has been reached". 

However, Henriques discloses receiving an additional packet associated with the request 
packet prior to establishing the protocol-based connection (see FIG. 8, steps 41,61,81, arriving 
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other/next/additional packet associated with request/query packet before setting/establishing the 
connection with available resources; see page 5, paragraph 48-52); 

assigning the additional packet to a pass-through class if the packet is forwarded (see 
FIG. 8, Step 87, 89, 91; assigning/allocation the other/next/additional packet to a transmit 
class/set/group if the packet is to be transmitted with available resources; see page 5, paragraph 
48-52); 

forwarding the additional packet from the pass-through class even if the first maximum 
count has been reached (see FIG. 8, Step 87, 89, 91; transmitting the other/next/additional packet 
from passing-through class/set/group (since the system is congestion mode, yet it is passing 
through the packet to transmit) even if the maximum/acceptable threshold/count has been exceed 
(which cases the system to go into congestion mode); see page 5, paragraph 48-52). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide assigning "if the packet is forwarded" and forwarding "even if 
the first maximum count has been reached" as taught by Henriques, in the combined system of 
Olsson and Barach, so that it would provide efficient policing function for a packet network; see 
Henriques page 2, paragraph 15-16. 

Regarding Claim 17, Olsson discloses an apparatus (see FIG. 2, node 200, see FIG. 3, 
node 300, or see FIG. 6, node 600) for managing connections in a network (see FIG. 2,3,6, 
control routing/forwarding in a exemplary PPP/IP network; see col. 5, line 66 to col. 6, line 10; 
see col. 7, line 46-67) comprising: 

a control plane (see FIG. 2,3,6, processor means 231, or 530; see col. 6, line 65 to col. 7, 
line 16, 30-34) operable to process protocol-based connection (see FIG. 6, PPP 620 or HDLC 
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530, processor processes PPP/HDLC connection packets; see col. 7, line 35-40,60-67; see col. 8, 
line 60-65); and 

a data plane (see FIG. 2-3, a combined system of network layer/plane 210 and data link 
layer/plane 220/310, or FIG. 6, a combined system of IP layer layer/plane 610, PPP layer/plane 
620 and HDLC layer/plane) operative to: 

receive a packet for establishing a protocol-based connection (see FIG. 2, receiving 
packet 21 1/212/213 at node 200/300/600 for PPP/IP connection; see FIG. 3, receiving Packet 
315-318 at node 200/300/600 for PPP/IP for setting-up connection; see col. 6, line 63 to col. 7, 
line 16,25-45; see col. 11, line 45-49), 

assign the packet to a selected one of a plurality of classes based upon a protocol of the 
connection (see FIG. 2, 3, 6, different QoS classification queues D1-D4, or DI.Dn, where Dl is 
for high QoS classification packets, and D N is lower QoS classification packets according to 
PPP/IP protocol of the connection; see col. 6, line 64 to col. 7, line 35; see col. 8, line 17-23, 60- 
65; see col. 9, line 44-45; see col. 11, line 43-50), 

forward the packet to the control plane (see FIG. 6, forward the packets from D N queues 
to data link layer/plane 530) to if the number of packets forwarded from the selected class (see 
FIG. 6, when packets each D1.D N QoS class) in a predetermined time interval (see FIG. 2,3,6, 
within scheduled/allocated time; see col. 6, line 60-65; see col. 8, line 27-30,44-65; see col. 9, 
line 17-42; see col. 10, line 30-40) has not reached a first maximum count (see FIG. 2,3,6, the 
size of queue; see col. 11, line 44-46; forwarding the packets when the specific QoS class queue 
D N is yet filled with packets); 



Application/Control Number: Page 36 

10/646,617 

Art Unit: 2416 

drop the packet if the number of packets forwarded from the selected class in the 
predetermined time interval has reached the first maximum count (see FIG. 2,3,6, discarding the 
packets when the specific QoS class queue D N in the scheduled/allocated time is full (i.e. 
reaching maximum packet number/count); see col. 11, line 35-55); 

receiving an addition packet associated with the packet prior to establishing the protocol- 
based connection (see FIG. 2, receiving subsequent/next packet 211/212/213 at node 
200/300/600 before setting up PPP/IP connection; see FIG. 3, receiving Packet 315-318 at 
node 200/300/600 for PPP/IP for setting-up connection; note that plurality of packets are 
received and routed/forward for connection(s); see col. 6, line 63 to col. 7, line 16,25-45; see 
col. 11, line 45-49); 

assigning the additional packet to a pass-through class if the packet is forwarded ( see 
FIG. 2, 3, 6, assigning next/subsequent packet with intermediate/pass-through class, that 
is, QoS class for neither high QoS or Lower QoS D2/D3 if the packet is forwarded/routed 
for connection; see col. 6, line 64 to col. 7, line 35; see col. 8, line 17-23, 60-65; see col. 9, line 
44-45; see col. 11, line 43-50); 

forwarding the additional packet from the pass-through class ( see FIG. 6, forward the 
packets with intermediate/pass-through class from D 2 /3 queues to data link layer/plane 530; 
see col. 6, line 60-65; see col. 8, line 27-30,44-65; see col. 9, line 17-42; see col. 10, line 30-40). 

Olsson does not explicitly disclose "a request packet" and "a protocol of the requested 
connection". 
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However, Barach discloses an apparatus (see FIG. 1, 2, Intermediate network node 200) 
for managing connections in a network (see FIG. 1, 2, control/managing routing/forwarding in a 
network 100; see col. 4, line 46 to col. 5, line 15) comprising: 

a control plane (see FIG. 2, a control plane includes entities used to manage/control 
operation of the node (e.g. a combined system of logic 220, route processor 270, RP module 260, 
system controller 280)) operative to process requests for protocol-based connection (see FIG. 2, 
processes requests (i.e. PPPoE Active Discovery Initiation (PADI) and Incoming Call Request 
(ICRQ)) for routing/forwarding for PPPoE/L2TP protocol based connection; see col. 2, line 4- 
24; see col. 5, line 29-64; see col. 6, line 20-30); and 

a data plane (see FIG. 2, a data plane includes components used to retrieve data packets 
(e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 230, and 
buffer 240)) operative to: 

receive a request packet for establishing a protocol-based connection (see FIG. 2, see 
FIG. 6, Step 610; receiving PADI/ICRQ request packet/PDU for establishing PPPoE/L2TP 
protocol based connection; see col. 5, line 28-46; see col. 6, line 20-30; see col. 8, line 35-45), 

forward the request packet to the control plane (see FIG. 2, forward PADI/ICRQ request 
packet/PDU to the control plane; see FIG. 6, Step 630, 640) to if the number of packets 
forwarded in a predetermined time interval (see FIG. 3, 4, FIG. 6, step 630, 640, when the 
number/count PADI/ICRQ request packet/PDU packets sent in predetermined time/clock 
interval; note that PDUs that cause to determine whether to route/forward or drop the 
connection are request PDUs) has not reached a first maximum count (see FIG. 3, FIG. 6, step 
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630, 640; is within the maximum/allowable predetermine number of time/clock); see col. 6, line 
36 to col. 7, line 65; see col. 8, line 35-67); 

drop the packet if the number of request packets forwarded in the predetermined time 
interval has reached the first maximum count (see FIG. 3, 4; FIG. 6, step 650, 660; drop the 
PADI/ICRQ request packet/PDU when the number/count of packets sent is greater than the 
allowable/acceptable predetermine time/clock interval; see col. 6, line 36 to col. 7, line 65; see 
col. 8, line 35-67); 

receiving an addition packet associated with the request packet prior to establishing the 
protocol-based connection (see FIG. 3, 4; FIG. 6, step 650, 660; subsequent/next 
packets/PDU that are associated/related to a first accepted and forwarded/routed 
PADI/ICRQ requested PDU before establishing the connection; note that plurality of PDUs 
are received and routed/forward for connection(s); see col. 6, line 36 to col. 7, line 65; see 
col. 8, line 35-65); 

forwarding the additional packet (see col. 6, line 36 to col. 7, line 65; see col. 8, line 35- 
6; see FIG. 3, 4, FIG. 6, step 630, 640; subsequent/next packets/PDU are also forwarded ). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a request packet" and "a protocol of the requested 
connection" as taught by Barach in the system of Olsson, so that it would provide more 
efficiently utilization of network resources which decreasing its latency of establishing a large 
number of new communication session as suggested by Barach; see Barach col. 3, line 1-30. 

Neither Olsson nor Barach explicitly discloses forwarding "even if the first maximum 
count has been reached". 
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However, Henriques discloses receiving an additional packet associated with the request 
packet prior to establishing the protocol-based connection (see FIG. 8, steps 41,61,81, arriving 
other/next/additional packet associated with request/query packet before setting/establishing the 
connection with available resources; see page 5, paragraph 48-52); 

assigning the additional packet to a pass-through class if the packet is forwarded (see 
FIG. 8, Step 87, 89, 91; assigning/allocation the other/next/additional packet to a transmit 
class/set/group if the packet is to be transmitted with available resources; see page 5, paragraph 
48-52); 

forwarding the additional packet from the pass-through class even if the first maximum 
count has been reached (see FIG. 8, Step 87, 89, 91; transmitting the other/next/additional packet 
from passing-through class/set/group (since the system is congestion mode, yet it is passing 
through the packet to transmit) even if the maximum/acceptable threshold/count has been exceed 
(which cases the system to go into congestion mode); see page 5, paragraph 48-52). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide assigning "if the packet is forwarded" and forwarding "even if 
the first maximum count has been reached" as taught by Henriques, in the combined system of 
Olsson and Barach, so that it would provide efficient policing function for a packet network; see 
Henriques page 2, paragraph 15-16. 

Regarding Claim 33, Olsson discloses a system (see FIG. 2, node 200, see FIG. 3, node 
300, or see FIG. 6, node 600) for managing connections in a network (see FIG. 2,3,6, control 
routing/forwarding in a exemplary PPP/IP network; see col. 5, line 66 to col. 6, line 10; see col. 
7, line 46-67) comprising: 
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means for receiving (see FIG. 2-3, a combined system of network layer/plane 210 and 
data link layer/plane 220/310, or FIG. 6, a combined system of IP layer layer/plane 610, PPP 
layer/plane 620 and HDLC layer/plane) a packet for establishing a protocol-based connection 
(see FIG. 2, receiving packet 211/212/213 at node 200/300/600 for PPP/IP connection; see FIG. 
3, receiving Packet 315-318 at node 200/300/600 for PPP/IP for setting-up connection; see col. 
6, line 63 to col. 7, line 16,25-45; see col. 11, line 45-49), 

means for assigning (see FIG. 2-3, a combined system of network layer/plane 210 and 
data link layer/plane 220/3 10, or FIG. 6, a combined system of IP layer layer/plane 610, PPP 
layer/plane 620 and HDLC layer/plane) the packet to a selected one of a plurality of classes 
based upon a protocol of the connection (see FIG. 2, 3, 6, different QoS classification queues 
D1-D4, or DI.Dn, where Dl is for high QoS classification packets, and Dn is lower QoS 
classification packets according to PPP/IP protocol of the connection; see col. 6, line 64 to col. 7, 
line 35; see col. 8, line 17-23, 60-65; see col. 9, line 44-45; see col. 11, line 43-50), 

means for forwarding (see FIG. 2-3, a combined system of network layer/plane 210 and 
data link layer/plane 220/3 10, or FIG. 6, a combined system of IP layer layer/plane 610, PPP 
layer/plane 620 and HDLC layer/plane) the packet to the control plane (see FIG. 6, forward the 
packets from D N queues to data link layer/plane 530) to if the number of packets forwarded from 
the selected class (see FIG. 6, when packets each D1.D N QoS class) in a predetermined time 
interval (see FIG. 2,3,6, within scheduled/allocated time; see col. 6, line 60-65; see col. 8, line 
27-30,44-65; see col. 9, line 17-42; see col. 10, line 30-40) has not reached a first maximum 
count (see FIG. 2,3,6, the size of queue; see col. 11, line 44-46; forwarding the packets when the 
specific QoS class queue D N is yet filled with packets); 



Application/Control Number: Page 41 

10/646,617 

Art Unit: 2416 

means for dropping (see FIG. 2-3, a combined system of network layer/plane 210 and 
data link layer/plane 220/310, or FIG. 6, a combined system of IP layer layer/plane 610, PPP 
layer/plane 620 and HDLC layer/plane) the packet if the number of packets forwarded from the 
selected class in the predetermined time interval has reached the first maximum count (see FIG. 
2,3,6, discarding the packets when the specific QoS class queue D N in the scheduled/allocated 
time is full (i.e. reaching maximum packet number/count); see col. 11, line 35-55); 

means for receiving an addition packet associated with the packet prior to establishing the 
protocol-based connection (see FIG. 2, receiving subsequent/next packet 211/212/213 at node 
200/300/600 before setting up PPP/IP connection; see FIG. 3, receiving Packet 315-318 at 
node 200/300/600 for PPP/IP for setting-up connection; note that plurality of packets are 
received and routed/forward for connection(s); see col. 6, line 63 to col. 7, line 16,25-45; see 
col. 11, line 45-49); 

means for assigning the additional packet to a pass-through class if the packet is 
forwarded ( see FIG. 2, 3, 6, assigning next/subsequent packet with intermediate/pass- 
through class, that is, QoS class for neither high QoS or Lower QoS D2/D3 if the packet is 
forwarded/routed for connection; see col. 6, line 64 to col. 7, line 35; see col. 8, line 17-23, 
60-65; see col. 9, line 44-45; see col. 11, line 43-50); 

means for forwarding the additional packet from the pass-through class ( see FIG. 6, 
forward the packets with intermediate/pass-through class from D 2 /3 queues to data link 
layer/plane 530; see col. 6, line 60-65; see col. 8, line 27-30,44-65; see col. 9, line 17-42; see 
col. 10, line 30-40). 
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Olsson does not explicitly disclose "a request packet" and "a protocol of the requested 
connection". 

Barach discloses a system (see FIG. 1, 2, Intermediate network node 200) for managing 
connections in a network (see FIG. 1, 2, control/managing routing/forwarding in a network 100; 
see col. 4, line 46 to col. 5, line 15) comprising: 

means for receiving (see FIG. 2, a data plane includes components used to retrieve data 
packets (e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 
230, buffer 240)) a request packet associated for establishing a protocol-based connection (see 
FIG. 2, see FIG. 6, Step 610; receiving PADI/ICRQ request packet/PDU for establishing 
PPPoE/L2TP protocol based connection; see col. 5, line 28-46; see col. 6, line 20-30; see col. 8, 
line 35-45); 

means for forwarding (see FIG. 2, a data plane includes components used to retrieve data 
packets (e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 
230, buffer 240)) the request packet if number of request packets forwarded from the selected 
class in a predetermined time interval (see FIG. 3, 4, FIG. 6, step 630, 640, when the 
number/count PADI/ICRQ request packet/PDU packets sent in predetermined time/clock 
interval; note that PDUs that cause to determine whether to route/forward or drop the 
connection are request PDUs) has not reached a first maximum count (see FIG. 3, FIG. 6, step 
630, 640; is within the maximum/allowable predetermine number of time/clock); see col. 6, line 
36 to col. 7, line 65; see col. 8, line 35-67); and 

means for dropping (see FIG. 2, a data plane includes components used to retrieve data 
packets (e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 



Application/Control Number: Page 43 

10/646,617 

Art Unit: 2416 

230, buffer 240)) the packet if number of request packets forwarded from the class in the 
predetermined time interval has reached the first maximum count (see FIG. 3, 4; FIG. 6, step 
650, 660; drop the PADI/ICRQ request packet/PDU when the number/count of request packets 
sent is greater than the allowable/acceptable predetermine time/clock interval; see col. 6, line 36 
to col. 7, line 65; see col. 8, line 35-67); 

means for receiving an addition packet associated with the request packet prior to 
establishing the protocol-based connection (see FIG. 3, 4; FIG. 6, step 650, 660; 
subsequent/next packets/PDU that are associated/related to a first accepted and 
forwarded/routed PADI/ICRQ requested PDU before establishing the connection; note 
that plurality of PDUs are received and routed/forward for connection(s); see col. 6, line 36 
to col. 7, line 65; see col. 8, line 35-65); 

means for forwarding the additional packet (see col. 6, line 36 to col. 7, line 65; see col. 
8, line 35-6; see FIG. 3, 4, FIG. 6, step 630, 640; subsequent/next packets/PDU are also 
forwarded ). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a request packet" and "a protocol of the requested 
connection" as taught by Barach in the system of Olsson, so that it would provide more 
efficiently utilization of network resources which decreasing its latency of establishing a large 
number of new communication session as suggested by Barach; see Barach col. 3, line 1-30. 

Neither Olsson nor Barach explicitly discloses forwarding "even if the first maximum 
count has been reached". 
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However, Henriques discloses means for receiving an additional packet associated with 
the request packet prior to establishing the protocol-based connection (see FIG. 8, steps 41,61, 
81, arriving other/next/additional packet associated with request/query packet before 
setting/establishing the connection with available resources; see page 5, paragraph 48-52); 

means for assigning the additional packet to a pass-through class if the packet is 
forwarded (see FIG. 8, Step 87, 89, 91; assigning/allocation the other/next/additional packet to a 
transmit class/set/group if the packet is to be transmitted with available resources; see page 5, 
paragraph 48-52); 

means for forwarding the additional packet from the pass-through class even if the first 
maximum count has been reached (see FIG. 8, Step 87, 89, 91; transmitting the 
other/next/additional packet from passing-through class/set/group (since the system is congestion 
mode, yet it is passing through the packet to transmit) even if the maximum/acceptable 
threshold/count has been exceed (which cases the system to go into congestion mode); see page 
5, paragraph 48-52). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide assigning "if the packet is forwarded" and forwarding "even if 
the first maximum count has been reached" as taught by Henriques, in the combined system of 
Olsson and Barach, so that it would provide efficient policing function for a packet network; see 
Henriques page 2, paragraph 15-16. 
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7. Claims 1,3,4, 13-15, 17, 19,20,29,30,31 and 33 are rejected under 35 U.S. C. 103(a) as 
being unpatentable over Olsson (US006577596B1) in view of Barach and further in view of 
Valencia (US006754712B1). 

Regarding Claim 1, Olsson discloses a method (see FIG. 2, node 200, see FIG. 3, node 
300, or see FIG. 6, node 600 processing the steps/methods) for managing connections in a 
network (see FIG. 2, 3, 6, control routing/forwarding in a exemplary PPP/IP network; see col. 5, 
line 66 to col. 6, line 10; see col. 7, line 46-67) comprising: 

receiving a packet for establishing a protocol-based connection (see FIG. 2, receiving 
packet 21 1/212/213 at node 200/300/600 for PPP/IP connection; see FIG. 3, receiving Packet 
315-318 at node 200/300/600 for PPP/IP for setting-up connection; see col. 6, line 63 to col. 7, 
line 16,25-45; see col. 11, line 45-49), 

assign the packet to a selected one of a plurality of classes based upon a protocol of the 
connection (see FIG. 2, 3, 6, different QoS classification queues D1-D4, or D1.D N , where Dl is 
for high QoS classification packets, and D N is lower QoS classification packets according to 
PPP/IP protocol of the connection; see col. 6, line 64 to col. 7, line 35; see col. 8, line 17-23, 60- 
65; see col. 9, line 44-45; see col. 11, line 43-50), 

forward the packet to the control plane (see FIG. 6, forward the packets from D N queues 
to data link layer/plane 530) to if the number of packets forwarded from the selected class (see 
FIG. 6, when packets each D1.D N QoS class) in a predetermined time interval (see FIG. 2,3,6, 
within scheduled/allocated time; see col. 6, line 60-65; see col. 8, line 27-30,44-65; see col. 9, 
line 17-42; see col. 10, line 30-40) has not reached a first maximum count (see FIG. 2,3,6, the 
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size of queue; see col. 11, line 44-46; forwarding the packets when the specific QoS class queue 
D N is yet filled with packets); 

drop the packet if the number of packets forwarded from the selected class in the 
predetermined time interval has reached the first maximum count (see FIG. 2,3,6, discarding the 
packets when the specific QoS class queue D N in the scheduled/allocated time is full (i.e. 
reaching maximum packet number/count); see col. 11, line 35-55); 

receiving an addition packet associated with the packet prior to establishing the protocol- 
based connection (see FIG. 2, receiving subsequent/next packet 211/212/213 at node 
200/300/600 before setting up PPP/IP connection; see FIG. 3, receiving Packet 315-318 at 
node 200/300/600 for PPP/IP for setting-up connection; note that plurality of packets are 
received and routed/forward for connection(s); see col. 6, line 63 to col. 7, line 16,25-45; see 
col. 11, line 45-49); 

assigning the additional packet to a pass-through class if the packet is forwarded ( see 
FIG. 2, 3, 6, assigning next/subsequent packet with intermediate/pass-through class, that 
is, QoS class for neither high QoS or Lower QoS D2/D3 if the packet is forwarded/routed 
for connection; see col. 6, line 64 to col. 7, line 35; see col. 8, line 17-23, 60-65; see col. 9, line 
44-45; see col. 11, line 43-50); 

forwarding the additional packet from the pass-through class according to the first 
maximum count ( see FIG. 6, forward the packets with intermediate/pass-through class from 
D 2 /3 queues to data link layer/plane 530 according to the size/fill-level/counts of packets in the 
queue; see col. 6, line 60-65; see col. 8, line 27-30, 44-65; see col. 9, line 17-42; see col. 10, 
line 30-40; see col. 11, line 44-46). 
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Olsson does not explicitly disclose "a request packet" and "a protocol of the requested 
connection". 

Barach discloses a method for managing connections (see FIG. I, 2, methods FIG. 6, 
Intermediate network node 200 processing/performing the steps/method controlling/managing 
routing/forwarding connections/sessions) in a network (see FIG. 1, 2, control/managing 
routing/forwarding in a network 100; see col. 4, line 46 to col. 5, line 15) comprising: 

receiving a request packet associated for establishing a protocol-based connection (see 
FIG. 2, see FIG. 6, Step 610; receiving PADI/ICRQ request packet/PDU for establishing 
PPPoE/L2TP protocol based connection; see col. 5, line 28-46; see col. 6, line 20-30; see col. 8, 
line 35-45); 

forwarding the request packet if a number of request packets forwarded in a 
predetermined time interval (see FIG. 3, 4, FIG. 6, step 630, 640, when the number/count 
PADI/ICRQ request packet/PDU packets sent in predetermined time/clock interval; note 
that PDUs that cause to determine whether to route/forward or drop the connection are 
request PDUs) has not reached a first maximum count (see FIG. 3, FIG. 6, step 630, 640; is 
within the maximum/allowable predetermine number of time/clock); see col. 6, line 36 to col. 7, 
line 65; see col. 8, line 35-67); and 

dropping the packet if number of request packets forwarded from the class in the 
predetermined time interval has reached the first maximum count (see FIG. 3, 4; FIG. 6, step 
650, 660; drop the PADI/ICRQ request packet/PDU when the number/count of request 
packets/PDUs sent is greater than the allowable/acceptable predetermine time/clock interval; see 
col. 6, line 36 to col. 7, line 65; see col. 8, line 35-67); 
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receiving an addition packet associated with the request packet prior to establishing the 
protocol-based connection (see FIG. 3, 4; FIG. 6, step 650, 660; subsequent/next 
packets/PDU that are associated/related to a first accepted and forwarded/routed 
PADI/ICRQ requested PDU before establishing the connection; note that plurality of PDUs 
are received and routed/forward for connection(s); see col. 6, line 36 to col. 7, line 65; see 
col. 8, line 35-65); 

forwarding the additional packet (see col. 6, line 36 to col. 7, line 65; see col. 8, line 35- 
6; see FIG. 3, 4, FIG. 6, step 630, 640; subsequent/next packets/PDU are also forwarded ). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a request packet" and "a protocol of the requested 
connection" as taught by Barach in the system of Olsson, so that it would provide more 
efficiently utilization of network resources which decreasing its latency of establishing a large 
number of new communication session as suggested by Barach; see Barach col. 3, line 1-30. 

Neither Olsson nor Barach explicitly discloses forwarding "even if the first maximum 
count has been reached". 

However, Valencia further discloses forwarding the additional packet even if the first 
maximum count has been reached (see col. 8, line 20-55; see col. 10, line 5-15; forwarding of 
management packets with sequence 0 and the counter is not increment, while the counted non- 
management packets are discarded. Thus it is clear that the management packets are sent even if 
the buffer/queue/resources/sequences reach its threshold/limit for non-management packets). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "requests and forwarding even if the first maximum count has 
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been reached", as taught by Valencia in the combined system of Olsson and Barach, so that it 
would provide layer two forwarding protocol with virtual dialup service and maintain security; 
see Valencia col. 1, line 65 to col. 2, line 37. 

Regarding Claim 3, Olsson discloses wherein the predetermined time interval is 
adjustable to effectuate different rates of packet forwarding for the selected class (see col. 9, line 
1-2; col. 12, line 30-40; scheduling time is adaptable to rate control of packet forwarding from a 
specific QoS class). 

Regarding Claim 4, Olsson discloses associated with the selected class is used to 
determine whether number of packets forwarded from the selected class in the predetermined 
time interval has reached the first maximum count (see col. 6, line 60-65; see col. 8, line 27-30, 
44-65; see col. 9, line 17-42; see col. 10, line 30-4; scheduling means determines the specific 
QoS class queue in the scheduled time/interval is full/reach maximum count). 

Olsson does not explicitly disclose "a counter". 

Barach discloses a counter (see FIG. 2, counter 296; see col. 6, line 1-10) associated with 
the type of resource is used to determine whether the number of packets forwarded from the class 
in the predetermined time interval has reached the first maximum count (see FIG. 3, 4; FIG. 6, 
step 650, 660; a counter 296 associated with the type of recourse is used to determine when the 
number/count of packets sent is greater than the allowable/acceptable predetermine time/clock 
interval; see col. 6, line 36 to col. 7, line 65; see col. 8, line 35-67). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a request packet" and "a protocol of the requested 
connection" as taught by Barach in the system of Olsson, so that it would provide more 
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efficiently utilization of network resources which decreasing its latency of establishing a large 
number of new communication session as suggested by Barach; see Barach col. 3, line 1-30. 

Regarding Claim 13, Olsson discloses wherein the protocol-based connection is based 
on a Point-to-Point Protocol (PPP) (see FIG. 6, PPP 620; see col. 7, line 35-40,60-67; see col. 8, 
line 60-65; PPP connection). Barach also discloses wherein the protocol-based connection is 
based on a Point-to-Point Protocol (PPP) (see col. 1, line 35-50, 65; see col. 2, line 5-20; see col. 
5, line 60-65; PPP connection). 

Regarding Claim 14, Olsson discloses the protocol-based connection as set forth above 
in claim 1 . 

Olsson does not explicitly disclose "Point-to-Point Protocol over Ethernet (PPPoE)". 

However, utilizing PPPoE is so well known in the art. In particular, Barach teaches 
wherein the protocol-based connection is based on a Point-to-Point Protocol over Ethernet 
(PPPoE) (see col. 5, line 28-46; see col. 6, line 20-30; see col. 8, line 35-45; PPPoE request 
(PADI) request packet/PDU for establishing PPPoE protocol based connection). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "PPPoE", as taught by Barach in the system of Olsson, so that 
it would provide more efficiently utilization of network resources which decreasing its latency of 
establishing a large number of new communication session as suggested by Barach; see Barach 
col. 3, line 1-30. 

Regarding Claim 15, Olsson discloses the protocol-based connection is based on a 
protocol of the connection as set forth above. 

Olsson does not explicitly disclose "a Layer Two Tunneling Protocol (L2TP)". 
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Barach discloses wherein the protocol-based connection is based on a Layer Two 
Tunneling Protocol (L2TP) (see col. 1, line 35-50, 65; see col. 2, line 5-20; see col. 5, line 60-65; 
layer 2 forwarding tunnels protocol (L2LP)). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a Layer Two Tunneling Protocol (L2TP)" as taught by 
Barach in the system of Olsson, so that it would provide more efficiently utilization of network 
resources which decreasing its latency of establishing a large number of new communication 
session as suggested by Barach; see Barach col. 3, line 1-30. 

Regarding Claim 17, Olsson discloses an apparatus (see FIG. 2, node 200, see FIG. 3, 
node 300, or see FIG. 6, node 600) for managing connections in a network (see FIG. 2,3,6, 
control routing/forwarding in a exemplary PPP/IP network; see col. 5, line 66 to col. 6, line 10; 
see col. 7, line 46-67) comprising: 

a control plane (see FIG. 2,3,6, processor means 231, or 530; see col. 6, line 65 to col. 7, 
line 16, 30-34) operable to process protocol-based connection (see FIG. 6, PPP 620 or HDLC 
530, processor processes PPP/HDLC connection packets; see col. 7, line 35-40,60-67; see col. 8, 
line 60-65); and 

a data plane (see FIG. 2-3, a combined system of network layer/plane 210 and data link 
layer/plane 220/310, or FIG. 6, a combined system of IP layer layer/plane 610, PPP layer/plane 
620 and HDLC layer/plane) operative to: 

receive a packet for establishing a protocol-based connection (see FIG. 2, receiving 
packet 211/212/213 at node 200/300/600 for PPP/IP connection; see FIG. 3, receiving Packet 
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315-318 at node 200/300/600 for PPP/IP for setting-up connection; see col. 6, line 63 to col. 7, 
line 16,25-45; see col. 11, line 45-49), 

assign the packet to a selected one of a plurality of classes based upon a protocol of the 
connection (see FIG. 2, 3, 6, different QoS classification queues D1-D4, or D1.D N , where Dl is 
for high QoS classification packets, and D N is lower QoS classification packets according to 
PPP/IP protocol of the connection; see col. 6, line 64 to col. 7, line 35; see col. 8, line 17-23, 60- 
65; see col. 9, line 44-45; see col. 11, line 43-50), 

forward the packet to the control plane (see FIG. 6, forward the packets from D N queues 
to data link layer/plane 530) to if the number of packets forwarded from the selected class (see 
FIG. 6, when packets each D1.D N QoS class) in a predetermined time interval (see FIG. 2,3,6, 
within scheduled/allocated time; see col. 6, line 60-65; see col. 8, line 27-30,44-65; see col. 9, 
line 17-42; see col. 10, line 30-40) has not reached a first maximum count (see FIG. 2,3,6, the 
size of queue; see col. 11, line 44-46; forwarding the packets when the specific QoS class queue 
D N is yet filled with packets); 

drop the packet if the number of packets forwarded from the selected class in the 
predetermined time interval has reached the first maximum count (see FIG. 2,3,6, discarding the 
packets when the specific QoS class queue D N in the scheduled/allocated time is full (i.e. 
reaching maximum packet number/count); see col. 11, line 35-55); 

receiving an addition packet associated with the packet prior to establishing the protocol- 
based connection (see FIG. 2, receiving subsequent/next packet 211/212/213 at node 
200/300/600 before setting up PPP/IP connection; see FIG. 3, receiving Packet 315-318 at 
node 200/300/600 for PPP/IP for setting-up connection; note that plurality of packets are 
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received and routed/forward for connection(s); see col. 6, line 63 to col. 7, line 16,25-45; see 
col. 11, line 45-49); 

assigning the additional packet to a pass-through class if the packet is forwarded ( see 
FIG. 2, 3, 6, assigning next/subsequent packet with intermediate/pass-through class, that 
is, QoS class for neither high QoS or Lower QoS D2/D3 if the packet is forwarded/routed 
for connection; see col. 6, line 64 to col. 7, line 35; see col. 8, line 17-23, 60-65; see col. 9, line 
44-45; see col. 11, line 43-50); 

forwarding the additional packet from the pass-through class according to the first 
maximum count ( see FIG. 6, forward the packets with intermediate/pass-through class from 
D 2 /3 queues to data link layer/plane 530 according to the size/fill-level/counts of packets in the 
queue; see col. 6, line 60-65; see col. 8, line 27-30,44-65; see col. 9, line 17-42; see col. 10, line 
30-40; see col. 11, line 44-46). 

Olsson does not explicitly disclose "a request packet" and "a protocol of the requested 
connection". 

However, Barach discloses an apparatus (see FIG. 1, 2, Intermediate network node 200) 
for managing connections in a network (see FIG. 1, 2, control/managing routing/forwarding in a 
network 100; see col. 4, line 46 to col. 5, line 15) comprising: 

a control plane (see FIG. 2, a control plane includes entities used to manage/control 
operation of the node (e.g. a combined system of logic 220, route processor 270, RP module 260, 
system controller 280)) operative to process requests for protocol-based connection (see FIG. 2, 
processes requests (i.e. PPPoE Active Discovery Initiation (PAD I) and Incoming Call Request 
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(ICRQ)) for routing/forwarding for PPPoE/L2TP protocol based connection; see col. 2, line 4- 
24; see col. 5, line 29-64; see col. 6, line 20-30); and 

a data plane (see FIG. 2, a data plane includes components used to retrieve data packets 
(e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 230, 
buffer 240)) operative to: 

receive a request packet for establishing a protocol-based connection (see FIG. 2, see 
FIG. 6, Step 610; receiving PADI/ICRQ request packet/PDU for establishing PPPoE/L2TP 
protocol based connection; see col. 5, line 28-46; see col. 6, line 20-30; see col. 8, line 35-45), 

forward the request packet to the control plane (see FIG. 2, forward PADI/ICRQ request 
packet/PDU to the control plane; see FIG. 6, Step 630, 640) to if the number of packets 
forwarded in a predetermined time interval (see FIG. 3, 4, FIG. 6, step 630, 640, when the 
number/count PADI/ICRQ request packet/PDU packets sent in predetermined time/clock 
interval; note that PDUs that cause to determine whether to route/forward or drop the 
connection are request PDUs) has not reached a first maximum count (see FIG. 3, FIG. 6, step 
630, 640; is within the maximum/allowable predetermine number of time/clock); see col. 6, line 
36 to col. 7, line 65; see col. 8, line 35-67); 

drop the packet if the number of request packets forwarded in the predetermined time 
interval has reached the first maximum count (see FIG. 3, 4; FIG. 6, step 650, 660; drop the 
PADI/ICRQ request packet/PDU when the number/count of packets sent is greater than the 
allowable/acceptable predetermine time/clock interval; see col. 6, line 36 to col. 7, line 65; see 
col. 8, line 35-67); 
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receiving an addition packet associated with the request packet prior to establishing the 
protocol-based connection (see FIG. 3, 4; FIG. 6, step 650, 660; subsequent/next 
packets/PDU that are associated/related to a first accepted and forwarded/routed 
PADI/ICRQ requested PDU before establishing the connection; note that plurality of PDUs 
are received and routed/forward for connection(s); see col. 6, line 36 to col. 7, line 65; see 
col. 8, line 35-65); 

forwarding the additional packet (see col. 6, line 36 to col. 7, line 65; see col. 8, line 35- 
6; see FIG. 3, 4, FIG. 6, step 630, 640; subsequent/next packets/PDU are also forwarded ). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a request packet" and "a protocol of the requested 
connection" as taught by Barach in the system of Olsson, so that it would provide more 
efficiently utilization of network resources which decreasing its latency of establishing a large 
number of new communication session as suggested by Barach; see Barach col. 3, line 1-30. 

Neither Olsson nor Barach explicitly discloses forwarding "even if the first maximum 
count has been reached". 

However, Valencia further discloses forwarding the additional packet even if the first 
maximum count has been reached (see col. 8, line 20-55; see col. 10, line 5-15; forwarding of 
management packets with sequence 0 and the counter is not increment, while the counted non- 
management packets are discarded. Thus it is clear that the management packets are sent even if 
the buffer/queue/resources/sequences reach its threshold/limit for non-management packets). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "requests and forwarding even if the first maximum count has 
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been reached", as taught by Valencia in the combined system of Olsson and Barach, so that it 
would provide layer two forwarding protocol with virtual dialup service and maintain security; 
see Valencia col. 1, line 65 to col. 2, line 37. 

Regarding Claim 19, Olsson discloses wherein the predetermined time interval is 
adjustable to effectuate different rates of packet forwarding for the selected class (see col. 9, line 
1-2; col. 12, line 30-40; scheduling time is adaptable to rate control of packet forwarding from a 
specific QoS class). 

Regarding Claim 20, Olsson discloses associated with the selected class is used to 
determine whether number of packets forwarded from the selected class in the predetermined 
time interval has reached the first maximum count (see col. 6, line 60-65; see col. 8, line 27-30, 
44-65; see col. 9, line 17-42; see col. 10, line 30-4; scheduling means determines the specific 
QoS class queue in the scheduled time/interval is full/reach maximum count). 

Olsson does not explicitly disclose "a counter". 

Barach discloses a counter (see FIG. 2, counter 296; see col. 6, line 1-10) associated with 
the type of resource is used to determine whether the number of packets forwarded from the class 
in the predetermined time interval has reached the first maximum count (see FIG. 3, 4; FIG. 6, 
step 650, 660; a counter 296 associated with the type of recourse is used to determine when the 
number/count of packets sent is greater than the allowable/acceptable predetermine time/clock 
interval; see col. 6, line 36 to col. 7, line 65; see col. 8, line 35-67). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a request packet" and "a protocol of the requested 
connection" as taught by Barach in the system of Olsson, so that it would provide more 
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efficiently utilization of network resources which decreasing its latency of establishing a large 
number of new communication session as suggested by Barach; see Barach col. 3, line 1-30. 

Regarding Claim 29, Olsson discloses wherein the protocol-based connection is based 
on a Point-to-Point Protocol (PPP) (see FIG. 6, PPP 620; see col. 7, line 35-40,60-67; see col. 8, 
line 60-65; PPP connection). Barach also discloses wherein the protocol-based connection is 
based on a Point-to-Point Protocol (PPP) (see col. 1, line 35-50, 65; see col. 2, line 5-20; see col. 
5, line 60-65; PPP connection). 

Regarding Claim 30, Olsson discloses the protocol-based connection as set forth above 
in claim 1 1 . 

Olsson does not explicitly disclose "Point-to-Point Protocol over Ethernet (PPPoE)". 

However, utilizing PPPoE is so well known in the art. In particular, Barach teaches 
wherein the protocol-based connection is based on a Point-to-Point Protocol over Ethernet 
(PPPoE) (see col. 5, line 28-46; see col. 6, line 20-30; see col. 8, line 35-45; PPPoE request 
(PADI) request packet/PDU for establishing PPPoE protocol based connection). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "PPPoE", as taught by Barach in the system of Olsson, so that 
it would provide more efficiently utilization of network resources which decreasing its latency of 
establishing a large number of new communication session as suggested by Barach; see Barach 
col. 3, line 1-30. 

Regarding Claim 31, Olsson discloses the protocol-based connection is based on a 
protocol of the connection as set forth above. 

Olsson does not explicitly disclose "a Layer Two Tunneling Protocol (L2TP)". 
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Barach discloses wherein the protocol-based connection is based on a Layer Two 
Tunneling Protocol (L2TP) (see col. 1, line 35-50, 65; see col. 2, line 5-20; see col. 5, line 60-65; 
layer 2 forwarding tunnels protocol (L2LP)). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a Layer Two Tunneling Protocol (L2TP)" as taught by 
Barach in the system of Olsson, so that it would provide more efficiently utilization of network 
resources which decreasing its latency of establishing a large number of new communication 
session as suggested by Barach; see Barach col. 3, line 1-30. 

Regarding Claim 33, Olsson discloses a system (see FIG. 2, node 200, see FIG. 3, node 
300, or see FIG. 6, node 600) for managing connections in a network (see FIG. 2,3,6, control 
routing/forwarding in a exemplary PPP/IP network; see col. 5, line 66 to col. 6, line 10; see col. 
7, line 46-67) comprising: 

means for receiving (see FIG. 2-3, a combined system of network layer/plane 210 and 
data link layer/plane 220/310, or FIG. 6, a combined system of IP layer layer/plane 610, PPP 
layer/plane 620 and HDLC layer/plane) a packet for establishing a protocol-based connection 
(see FIG. 2, receiving packet 21 1/212/213 at node 200/300/600 for PPP/IP connection; see FIG. 
3, receiving Packet 315-318 at node 200/300/600 for PPP/IP for setting-up connection; see col. 
6, line 63 to col. 7, line 16,25-45; see col. 11, line 45-49), 

means for assigning (see FIG. 2-3, a combined system of network layer/plane 210 and 
data link layer/plane 220/310, or FIG. 6, a combined system of IP layer layer/plane 610, PPP 
layer/plane 620 and HDLC layer/plane) the packet to a selected one of a plurality of classes 
based upon a protocol of the connection (see FIG. 2, 3, 6, different QoS classification queues 
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D1-D4, or D1.D N , where Dl is for high QoS classification packets, and D N is lower QoS 
classification packets according to PPP/IP protocol of the connection; see col. 6, line 64 to col. 7, 
line 35; see col. 8, line 17-23, 60-65; see col. 9, line 44-45; see col. 11, line 43-50), 

means for forwarding (see FIG. 2-3, a combined system of network layer/plane 210 and 
data link layer/plane 220/310, or FIG. 6, a combined system of IP layer layer/plane 610, PPP 
layer/plane 620 and HDLC layer/plane) the packet to the control plane (see FIG. 6, forward the 
packets from D N queues to data link layer/plane 530) to if the number of packets forwarded from 
the selected class (see FIG. 6, when packets each Dl .D N QoS class) in a predetermined time 
interval (see FIG. 2,3,6, within scheduled/allocated time; sec col. 6, line 60-65; see col. 8, line 
27-30,44-65; see col. 9, line 17-42; see col. 10, line 30-40) has not reached a first maximum 
count (see FIG. 2,3,6, the size of queue; see col. 11, line 44-46; forwarding the packets when the 
specific QoS class queue D N is yet filled with packets); 

means for dropping (see FIG. 2-3, a combined system of network layer/plane 210 and 
data link layer/plane 220/310, or FIG. 6, a combined system of IP layer layer/plane 610, PPP 
layer/plane 620 and HDLC layer/plane) the packet if the number of packets forwarded from the 
selected class in the predetermined time interval has reached the first maximum count (see FIG. 
2,3,6, discarding the packets when the specific QoS class queue D N in the scheduled/allocated 
time is full (i.e. reaching maximum packet number/count); see col. 11, line 35-55); 

means for receiving an addition packet associated with the packet prior to establishing the 
protocol-based connection (see FIG. 2, receiving subsequent/next packet 211/212/213 at node 
200/300/600 before setting up PPP/IP connection; see FIG. 3, receiving Packet 315-318 at 
node 200/300/600 for PPP/IP for setting-up connection; note that plurality of packets are 
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received and routed/forward for connection(s); see col. 6, line 63 to col. 7, line 16,25-45; see 
col. 11, line 45-49); 

means for assigning the additional packet to a pass-through class if the packet is 
forwarded ( see FIG. 2, 3, 6, assigning next/subsequent packet with intermediate/pass- 
through class, that is, QoS class for neither high QoS or Lower QoS D2/D3 if the packet is 
forwarded/routed for connection; see col. 6, line 64 to col. 7, line 35; see col. 8, line 17-23, 
60-65; see col. 9, line 44-45; see col. 11, line 43-50); 

means for forwarding the additional packet from the pass-through class ( see FIG. 6, 
forward the packets with intermediate/pass-through class from D 2 /s queues to data link 
layer/plane 530 according to the size/fill-level/counts of packets in the queue; see col. 6, line 
60-65; see col. 8, line 27-30,44-65; see col. 9, line 17-42; see col. 10, line 30-40; see col. 11, 
line 44-46). 

Olsson does not explicitly disclose "a request packet" and "a protocol of the requested 
connection". 

Barach discloses a system (see FIG. 1, 2, Intermediate network node 200) for managing 
connections in a network (see FIG. 1, 2, control/managing routing/forwarding in a network 100; 
see col. 4, line 46 to col. 5, line 15) comprising: 

means for receiving (see FIG. 2, a data plane includes components used to retrieve data 
packets (e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 
230, buffer 240)) a request packet associated for establishing a protocol-based connection (see 
FIG. 2, see FIG. 6, Step 610; receiving PADWCRQ request packet/PDU for establishing 
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PPPoE/L2TP protocol based connection; see col. 5, line 28-46; see col. 6, line 20-30; see col. 8, 
line 35-45); 

means for forwarding (see FIG. 2, a data plane includes components used to retrieve data 
packets (e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 
230, buffer 240)) the request packet if number of request packets forwarded from the selected 
class in a predetermined time interval (see FIG. 3, 4, FIG. 6, step 630, 640, when the 
number/count PADI/ICRQ request packet/PDU packets sent in predetermined time/clock 
interval; note that PDUs that cause to determine whether to route/forward or drop the 
connection are request PDUs) has not reached a first maximum count (see FIG. 3, FIG. 6, step 
630, 640; is within the maximum/allowable predetermine number of time/clock); see col. 6, line 
36 to col. 7, line 65; see col. 8, line 35-67); and 

means for dropping (see FIG. 2, a data plane includes components used to retrieve data 
packets (e.g. a combined system of line cards 210, links 212, forwarding engine 250, FP module 
230, buffer 240)) the packet if number of request packets forwarded from the class in the 
predetermined time interval has reached the first maximum count (see FIG. 3, 4; FIG. 6, step 
650, 660; drop the PADI/ICRQ request packet/PDU when the number/count of request packets 
sent is greater than the allowable/acceptable predetermine time/clock interval; see col. 6, line 36 
to col. 7, line 65; see col. 8, line 35-67); 

means for receiving an addition packet associated with the request packet prior to 
establishing the protocol-based connection (see FIG. 3, 4; FIG. 6, step 650, 660; 
subsequent/next packets/PDU that are associated/related to a first accepted and 
forwarded/routed PADI/ICRQ requested PDU before establishing the connection; note 
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that plurality of PDUs are received and routed/forward for connection(s); see col. 6, line 36 
to col. 7, line 65; see col. 8, line 35-65); 

means for forwarding the additional packet (see col. 6, line 36 to col. 7, line 65; see col. 
8, line 35-6; see FIG. 3, 4, FIG. 6, step 630, 640; subsequent/next packets/PDU are also 
forwarded ). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a request packet" and "a protocol of the requested 
connection" as taught by Barach in the system of Olsson, so that it would provide more 
efficiently utilization of network resources which decreasing its latency of establishing a large 
number of new communication session as suggested by Barach; see Barach col. 3, line 1-30. 

Neither Olsson nor Barach explicitly discloses forwarding "even if the first maximum 
count has been reached". 

However, Valencia further discloses forwarding the additional packet even if the first 
maximum count has been reached (see col. 8, line 20-55; see col. 10, line 5-15; forwarding of 
management packets with sequence 0 and the counter is not increment, while the counted non- 
management packets are discarded. Thus it is clear that the management packets are sent even if 
the buffer/queue/resources/sequences reach its threshold/limit for non-management packets). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "requests and forwarding even if the first maximum count has 
been reached", as taught by Valencia in the combined system of Olsson and Barach, so that it 
would provide layer two forwarding protocol with virtual dialup service and maintain security; 
see Valencia col. 1, line 65 to col. 2, line 37. 
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8. Claims 2 and 18 are rejected under 35 U.S.C. 103(a) as being unpatentable over Olsson in 
view of Barach and Valencia, and further in view of Kroll (US006700895B1) 

Regarding Claim 2, Olsson discloses wherein the first maximum count effectuates 
different rates of packet forwarding for the selected class (see FIG. 2,3,6, the size of each 
specific QoS class queue D N effects/results different rates for forwarding high and low QoS 
classes of packets; see col. 11, line 44-46). 

Neither Olsson, Barach nor Valencia explicitly discloses "adjustable". 

However, adjusting queues or buffer size length for different rates is so well known in the 
art. In particular, Kroll teaches wherein the first maximum count is adjustable to effectuate 
different rates of packet forwarding (see FIG. 6, SI 94, 196; the buffer size is increased/adjusted 
to accommodate/effects more counts of packet so that more/higher data rate with desired loss 
rate can be processed; see col. 7, line 10-24). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide adjustable first maximum count, as taught by Kroll in the 
combined system of Olsson, Barach and Valencia, so that it would provide an optimal buffer 
size; see Kroll col. 2, line 30-55. 

Regarding Claim 18, Olsson discloses wherein the first maximum count effectuates 
different rates of packet forwarding for the selected class (see FIG. 2,3,6, the size of each 
specific QoS class queue D N effects/results different rates for forwarding high and low QoS 
classes of packets; see col. 11, line 44-46). 

Neither Olsson, Barach nor Valencia explicitly discloses "adjustable". 
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However, adjusting queues or buffer size/length for different rates is so well known in the 
art. In particular, Kroll teaches wherein the first maximum count is adjustable to effectuate 
different rates of packet forwarding (see FIG. 6, SI 94, 196; the buffer size is increased/adjusted 
to accommodate/effects more counts of packet so that more/higher data rate with desired loss 
rate can be processed; see col. 7, line 10-24). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide adjustable first maximum count, as taught by Kroll in the 
combined system of Olsson, Barach and Valencia, so that it would provide an optimal buffer 
size; see Kroll col. 2, line 30-55. 

9. Claim 5 and 21 are rejected under 35 U.S.C. 103(a) as being unpatentable over Olsson in 
view of Barach and Valencia as applied to claims above, and further in view of Kim 
(US005859846A). 

Regarding Claim 5, the combined system of Olsson, Barach and Valencia discloses the 
counter as set forth above in claim 1 . 

Neither Olsson, Barach nor Valencia explicitly discloses "a count-down" counter. 

However, having a count-down counter for the buffer or queue is so well known in the 
art. In particular, Kim discloses a counter (see FIG. 5, UP/Down counter 27) associated with the 
selected class (see FIG. 5, Shared buffer 28) is used to determine whether number of packets 
forwarded from the selected class has reached the first maximum count (see col. 13, line 21-45; a 
counter associated with a shared buffer is used to determined whether the number of cells 
forwarded from the buffer (i.e. determining full/maximum number of cells in the buffer)), 
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wherein the counter is a count-down counter (see FIG. 5, Down counter 27; see col. 13, line 21- 
45). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a count-down counter", as taught by Kim, in the combined 
system of Olsson, Barach and Valencia, so that it would count the number of cells stored/output 
from the buffer; see Kim col. 16, line 22-27. 

Regarding Claim 21, the combined system of Olsson, Barach and Valencia discloses the 
counter as set forth above in claim 17. 

Neither Olsson, Barach nor Valencia explicitly discloses "a count-down" counter. 

However, having a count-down counter for the buffer or queue is so well known in the 
art. In particular, Kim discloses a counter (see FIG. 5, UP/Down counter 27) associated with the 
selected class (see FIG. 5, Shared buffer 28) is used to determine whether number of packets 
forwarded from the selected class has reached the first maximum count (see col. 13, line 21-45; a 
counter associated with a shared buffer is used to determined whether the number of cells 
forwarded from the buffer (i.e. determining full/maximum number of cells in the buffer)), 
wherein the counter is a count-down counter (see FIG. 5, Down counter 27; see col. 13, line 21- 
45). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "a count-down counter", as taught by Kim, in the combined 
system of Olsson, Barach and Valencia, so that it would count the number of cells stored/output 
from the buffer; see Kim col. 16, line 22-27. 
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10. Claim 6, 8, 9, 1 1, 12, 22, 24, 25, 27 and 28 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Olsson in view of Barach and Valencia as applied to claim 1 and 17 above, 
and further in view of Choudhury (US0060921 15 A). 

Regarding Claims 6 and 22, the combined system of Olsson, Barach and Valencia 
discloses wherein the request packet is forwarded only if a count of active connection requests 
has not reached a maximum limit, and Olsson disclosing receiving and forwarding the 
next/subsequence packets for which the connections have not setup/established as set as set forth 
above in claims. 

Neither Olsson, Barach nor Valencia explicitly discloses "a second maximum limit". 

However, buffer or queue having an overflow bandwidth or borrowed space having 
another/second size/threshold to accommodate the extra packets is so well known in the art. 
Choudhury discloses wherein the packet is forwarded only if a count of active connection 
packets has not reached a second maximum limit (see FIG. 2, the packet is forward when a 
count/number of active packets has not reach the limit/size/threshold of underutilized queue 30c; 
see col. 4, line 1-15. 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide a second maximum limit, as taught by Choudhury, in the 
combined system of Olsson, Barach and Valencia, so that it would provide fair queuing schemes; 
see Choudhury col. 2, line 44-60. 

Regarding Claim 8, Olsson discloses the count of active connection is decremented 
upon the protocol-based connection (see FIG. 6, when number/count of active packets is 
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forwarded from the o D N queues upon a PPP/HDLC connation, the number/count of packets in 
the queue is decreased/decremented; see col. 11, line 44-46). 
Olsson does explicitly disclose "requests". 

However, Barach discloses the count of active connection requests for establishment a 
protocol-based connection (see col. 6, line 1 to col. 8, line 35; number/counts of connection 
requests for establishing of PPPoE/L2TP connection). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "requests", as taught by Barach, in the system of Olsson, for 
the same motivation as set forth above in claim 1 . 

Regarding Claim 9, Olsson discloses the count of active connection is decremented 
upon the protocol-based connection (see FIG. 6, when number/count of active packets is 
forwarded from the o D N queues upon a PPP/HDLC connation, the number/count of packets in 
the queue is decreased/decremented; see col. 1 1 , line 44-46). 

Olsson does explicitly disclose "requests". 

However, Barach discloses the count of active connection requests when a protocol-based 
connection is terminated before being established (see col. 6, line 1 to col. 8, line 35; 
number/count of connection requests and termination/disconnection before establishing 
PPPoE/L2TP connection). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "termination/disconnection before establishing the 
connection", as taught by Barach, in the system of Olsson, for the same motivation as set forth 
above in claim 1 . 
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In addition, Choudhury also discloses the count of active connection packets are 
decremented in the queue due to forwarding packets when a connection is terminated (see col. 9, 
line 2-9). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "termination/disconnection before establishing the 
connection", as taught by Choudhury, in the combined system of Olsson and Barach, for the 
same motivation as set forth above in claim 1. 

Regarding Claim 11, the combined system of Olsson and Barach discloses the 
additional packet and the requested protocol-based connection as set forth in claims above. 

Neither Olsson nor Barach explicitly disclose "relates to status" of the requested 
protocol-based connection". 

However, Valencia discloses wherein the additional packet relates to status of the 
requested protocol-based connection (see col. 8, line 20-55; see col. 10, line 5-15; see col. 11, 
line 40-55; the management packets relates to status of PPP/L2F connection such as 
configuration, authentication, response, etc.). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "relates to status of the requested protocol-based connection", 
as taught by Valencia in the combined system of Olsson and Barach, so that it would provide 
layer two forwarding protocol with virtual dialup service and maintain security; see Valencia col. 
l,line 65 to col. 2, line 37. 

Regarding Claim 12, combined system of Olsson and Barach discloses the additional 
packet and the requested protocol-based connection as set forth in claims above. 
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Neither Olsson nor Barach explicitly disclose "relates to termination" of the requested 
protocol-based connection". 

Valencia discloses wherein the additional packet relates to termination of the requested 
protocol-based connection (see col. 8, line 20-55; see col. 10, line 5-15; see col. 11, line 40-55; 
the management packets relates to disconnection/termination of PPP/L2F connection). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "relates to termination" of the requested protocol-based 
connection, as taught by Valencia in the combined system of Olsson and Barach so that it would 
provide layer two forwarding protocol with virtual dialup service and maintain security; see 
Valencia col. 1, line 65 to col. 2, line 37. 

Regarding Claim 24, Olsson discloses the count of active connection is decremented 
upon the protocol-based connection (see FIG. 6, when number/count of active packets is 
forwarded from the o D N queues upon a PPP/HDLC connation, the number/count of packets in 
the queue is decreased/decremented; see col. 11, line 44-46). 

Olsson does explicitly disclose "requests". 

However, Barach discloses the count of active connection requests for establishment a 
protocol-based connection (see col. 6, line 1 to col. 8, line 35; sending connection requests for 
establishing connection). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "requests", as taught by Barach, in the system of Olsson, for 
the same motivation as set forth above in claim 17. 
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Regarding Claim 25, Olsson discloses the count of active connection is decremented 
upon the protocol-based connection (see FIG. 6, when number/count of active packets is 
forwarded from the o D N queues upon a PPP/HDLC connation, the number/count of packets in 
the queue is decreased/decremented; see col. 1 1 , line 44-46). 

Olsson does explicitly disclose "requests". 

However, Barach discloses the count of active connection requests when a protocol-based 
connection is terminated before being established (see col. 6, line 1 to col. 8, line 35; 
number/count of connection requests and termination/disconnection before establishing 
PPPoE/L2TP connection). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "termination/disconnection before establishing the 
connection", as taught by Barach, in the system of Olsson, for the same motivation as set forth 
above in claim 17. 

In addition, Choudhury also discloses the count of active connection packets are 
decremented in the queue due to forwarding packets when a connection is terminated (see col. 9, 
line 2-9). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "termination/disconnection before establishing the 
connection", as taught by Choudhury, in the combined system of Olsson and Barach, for the 
same motivation as set forth above in claim 17. 

Regarding Claim 27, the combined system of Olsson, and Barach discloses the 
additional packet and the requested protocol-based connection as set forth in claims above. 
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Neither Olsson, nor Barach explicitly disclose "relates to status" of the requested 
protocol-based connection". 

However, Valencia discloses wherein the additional packet relates to status of the 
requested protocol-based connection (see col. 8, line 20-55; see col. 10, line 5-15; see col. 11, 
line 40-55; the management packets relates to status of PPP/L2F connection such as 
configuration, authentication, response, etc.). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "relates to status of the requested protocol-based connection", 
as taught by Valencia in the combined system of Olsson, and Barach, so that it would provide 
layer two forwarding protocol with virtual dialup service and maintain security; see Valencia col. 
1, line 65 to col. 2, line 37. 

Regarding Claim 28, combined system of Olsson, and Barach discloses the additional 
packet and the requested protocol-based connection as set forth above in claim 1 1, 22 and 26. 

Neither Olsson, nor Barach explicitly disclose "relates to termination" of the requested 
protocol-based connection". 

Valencia discloses wherein the additional packet relates to termination of the requested 
protocol-based connection (see col. 8, line 20-55; see col. 10, line 5-15; see col. 11, line 40-55; 
the management packets relates to disconnection/termination of PPP/L2F connection). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "relates to termination" of the requested protocol-based 
connection, as taught by Valencia in the combined system of Olsson and Barach so that it would 
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provide layer two forwarding protocol with virtual dialup service and maintain security; see 
Valencia col. 1, line 65 to col. 2, line 37. 



1 1 . Claim 6, 7, 22 and 23 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Olsson in view of Barach and Valencia as applied to claims above, and further in view of Suzuki 
(US005140584A). 

Regarding Claims 6 and 22, the combined system of Olsson, Barach and Valencia 
discloses wherein the request packet is forwarded only if a count of active connection requests 
has not reached a maximum limit, and Olsson disclosing receiving and forwarding the 
next/subsequence packets for which the connections have not setup/established as set as set forth 
above in claims. 

Neither Olsson, Barach nor Valencia explicitly discloses "a second maximum limit". 

However, buffer or queue having second maximum threshed/limit count is so well known 
in the art. Suzuki discloses wherein the packet is forwarded only if a count of active connection 
packets has not reached a second maximum limit (see FIG. 3, comparing the packet according 
secondary Thresholds, Thr2-Thr4, before forwarding the packets; see col. 4, line 25-64; see col. 
8, line 1-5,50-60). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide a second maximum limit, as taught by Suzuki, in the 
combined system of Olsson. Barach and Valencia, so that it would obtain a transmission quality 
which has high instantaneousness; see Suzuki col. 2, line 40-45. 
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Regarding Claims 7 and 23, Olsson discloses wherein the count of active connection is 
increment when the packet is forwarded to the selected class (see FIG. 6, when number/count of 
active packets is forwarded to the o D N queues upon a PPP/HDLC connation, the number/count 
of packets in the queue is increment/increased; see col. 11, line 44-46). 

Olsson does not explicitly disclose "request packet". 

However, Barach discloses request packet as set forth above in claim 1 . 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "requests", as taught by Barach, in the combined system of 
Olsson and Barach, for the same motivation as set forth above in claim 1 . 

Further more, Suzuki further discloses the count of active connection packet is 
incremented when a packet is forwarded (see FIG. 3, counter 5 is incremented when a packet for 
a connection is forwarded; see col. 7, line 50-55). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide "the count of active connection packet is incremented when 
the packet is forwarded", as taught by Suzuki, in the combined system of Olsson, Barach and 
Valencia, for the same motivation as set forth above in claim 6. 

12. Claims 16 and 32 are rejected under 35 U.S.C. 103(a) as being unpatentable over Olsson 
in view of Barach and Valencia as applied to claims 1 and 17 above, and further in view of 
Xiong (US006958996B2) 

Regarding Claim 16, the combined system of Olsson, Barach and Valencia discloses 
wherein the protocol-based connection as set forth above in claim 1 . 
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Neither Olsson, Barach nor Valencia explicitly discloses a Dynamic Host Configuration 
Protocol (DHCP). 

However, utilizing DHCP is so well known in the art. In particular, Xiong teaches 
wherein the protocol-based connection is based on a Dynamic Host Configuration Protocol 
(DHCP) (see FIG. 6, DHCP request; see col. 2, line 40-60; see col. 5, line 10-45). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide DHCP, as taught by Xiong in the combined system of Olsson, 
Barach and Valencia, so that it would enable a client for communication with ISP over the 
internet by utilizing appropriate address; sec Xiong col. 2, line 40-45. 

Regarding Claim 32, the combined system of Olsson, Barach and Valencia discloses 
wherein the protocol-based connection as set forth above in claim 17. 

Neither Olsson, Barach nor Valencia explicitly discloses a Dynamic Host Configuration 
Protocol (DHCP). 

However, utilizing DHCP is so well known in the art. In particular, Xiong teaches 
wherein the protocol-based connection is based on a Dynamic Host Configuration Protocol 
(DHCP) (see FIG. 6, DHCP request; see col. 2, line 40-60; see col. 5, line 10-45). 

Therefore, it would have been obvious to one having ordinary skill in the art at the time 
the invention was made to provide DHCP, as taught by Xiong in the combined system of Olsson, 
Barach and Valencia, so that it would enable a client for communication with ISP over the 
internet by utilizing appropriate address; see Xiong col. 2, line 40-45. 
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Conclusion 

13. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 
Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a). 

A shortened statutory period for reply to this final action is set to expire THREE 
MONTHS from the mailing date of this action. In the event a first reply is filed within TWO 
MONTHS of the mailing date of this final action and the advisory action is not mailed until after 
the end of the THREE-MONTH shortened statutory period, then the shortened statutory period 
will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 
CFR 1 .136(a) will be calculated from the mailing date of the advisory action. In no event, 
however, will the statutory period for reply expire later than SIX MONTHS from the date of this 
final action. 

14. Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to IAN N. MOORE whose telephone number is (571)272-3085. 
The examiner can normally be reached on 9:00 AM- 6:00 PM. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, William Trost can be reached on 571-272-7872. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

Ian N. Moore 
Primary Examiner 
Art Unit 2416 

/Ian N. Moore/ 

Primary Examiner, Art Unit 2616 



